https://sebokwiki.org/w/api.php?action=feedcontributions&user=Mhaas&feedformat=atom
SEBoK - User contributions [en]
2024-03-28T08:48:46Z
User contributions
MediaWiki 1.35.13
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Enterprise_IT&diff=66945
Systems Engineering and Enterprise IT
2023-05-07T04:08:33Z
<p>Mhaas: Fixed spacing and links</p>
<hr />
<div>----<br />
'''''Lead Authors:''''' Chuck Walrad and Richard Hilliard<br />
----<br />
This article forms part of the [[Related Disciplines]] knowledge area (KA). It discusses enterprise IT, building upon the concepts and practices of Systems Engineering presented elsewhere in the SEBOK. Systems Engineering is integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of ''engineered technical systems''. <br />
<br />
== Enterprise IT Introduction==<br />
Although it had its origin in the need to improve success rates in U.S. Government outsourcing of technical systems, Systems Engineering is also integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of [https://www.incose.org/about-systems-engineering/system-and-se-definition/systems-engineering-definition#ENGINEERED_SYSTEM engineered technical systems].<br />
Examples of EIT systems include enterprise resource planning, supply chain management and customer relationship management systems, accounting, finance, inventory and order management, marketing, planning, purchasing, and sales.<br />
In the late 1980s and throughout the 1990s, EIT organizations became increasingly aware that the success rates of IT projects were very low, and that their enterprise customers were increasingly unhappy with their EIT investments. The Standish Group sought to understand what was going on. Their findings were presented in the [https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf Chaos Report] (1994):<br />
The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable but could easily be in the trillions of dollars.<br />
<br />
As a result, commercial IT organizations, through the auspicious parallel emergence of the Total Quality Management movement and the increasingly widespread development of application development methodologies (ADM) by IT management consulting firms, recognized the need for the principles of Systems Engineering and cross-functional teams (Integrated Product Teams [https://www.sebokwiki.org/wiki/Integrated_Product_Team_(IPT)_(glossary)]. It should be noted that there is considerable overlap today between what constitutes Systems Engineering and what constitutes [[Portfolio Management|Relationships between Systems Engineering and Project Management]] (see [https://www.pmi.org/learning/library/bridging-gap-program-management-systems-engineering-6213 PMI]). This article does not attempt to resolve this issue. Note that the “[[Related Business Activities|following business management activities]] can be ''supported'' by enterprise systems engineering (ESE) activities” [emphasis added]: <br />
* mission and strategic planning,<br />
* business processes and information management,<br />
* performance management,<br />
* portfolio management,<br />
* resource allocation and budgeting, and<br />
* program and project management.<br />
<br />
Note that these same areas have been designated as being supported by Project Management Offices. However, since a key difference between project management and systems engineering has been identified as the requirement that the latter includes technical expertise in the product/system of concern, focus should be on systems engineering and integrated product teams (IPTs). <br />
With IPTs, each product is shepherded from concept through delivery and support to retirement by a cross-functional team that includes representatives from each area of responsibility, such as customer requirements development, design and development, test, configuration management, release engineering, delivery, and support.<br />
As enterprises have come to depend more and more on technology to perform effectively, Enterprise IT organizations have matured, often due to the influence of IT consulting firms that make it their business to keep abreast of best practices.<br />
<br />
== EIT Concepts ==<br />
This knowledge area (KA) discusses enterprise IT, building upon the concepts elucidated in the IEEE/ACM ''[http://eitbokwiki.org EITBOK Guide to the Enterprise Information Technology Body of Knowledge]'' and general concepts of Systems Engineering elsewhere in SEBOK. <br />
<br />
An enterprise may be viewed from various perspectives: such as a system or a [[Enterprise Systems Engineering|system of systems (SoS)]]:<br />
<br />
* system-like enterprise: enterprises, like other systems, may have a tight coupling, single-executive function; <br />
* system of systems-like enterprise: may be a loosely coupled group of organizations with blurred boundaries and (yet) with (some) shared outcomes.<br />
<br />
The choice of perspective may vary with many factors: the enterprise itself, the mission or purpose, or the particular engineering task at hand. We can view an enterprise as a system with inputs and outputs in relation to the outside world, or a system of systems interacting through their individual inputs and outputs. <br />
<br />
An enterprise usually involves one (or more) organization(s) but need not be identified with the organization. As the scope of human and organizational participants of the enterprise widen, there may be no single point of control. For example, an ''extended enterprise'' could include a company, its suppliers and customers.<br />
<br />
Whatever perspective (system-like, SoS-like, other) is taken there are [[Enterprise Systems Engineering Background|key ingredients]] of any enterprise: capabilities, individual (competencies) and the organizational design. [[Enterprise Capability Management|Capabilities]] can be further categorized: “There are three different kinds of capability: organizational capability, system capability, and operational capability.” These capabilities determine what the enterprise is able to produce which may be external offerings or internal mechanisms. Operational capabilities create services and/or products which in turn produce value as determined by stakeholders. The capabilities of an enterprise are realized through [[Enterprise Systems Engineering Background|various enterprise elements]], including: “hardware, software, personnel, facilities, data, materials, techniques, and even services”. which include “soft” items, like people, processes, principles, policies, practices, organizations, doctrine, theories, and beliefs.<br />
<br />
EIT capabilities exist through lifecycles spanning from creation through eventual replacement and disposal. ''Life cycle models'' are schemes to aid in the understanding, design, planning and management of the capability of interest. <br />
<br />
“A life cycle for a system generally consists of a series of stages regulated by a set of management decisions which confirm that the system is mature enough to leave one stage and enter another.” Basic life cycle terms and concepts are discussed in [[Systems Lifecycle Approaches]]. Some typical life cycles are discussed in [[System Lifecycle Models]].<br />
<br />
A life cycle-based approach can be deployed across the several levels and used to manage evolution. These levels are:<br />
* the enterprise itself,<br />
* the processes and organizations constituting the enterprise,<br />
* the systems enabling the capabilities, services or products provided. <br />
<br />
It is important to distinguish between ''product'' and ''project'' lifecycle models. A product’s life cycle extends from its initial concept approval, through development and distribution, to its retirement. This is the cycle that is managed within an Enterprise IT organization, since EIT must manage the hardware or software product from its introduction, in the case of acquired capabilities, or from its concept approval and development, in the case of capabilities it builds, through its deployment, maintenance and eventual retirement (withdrawal). Each of these stages is usually managed as a project or a series of projects.<br />
<br />
However, most discussions of life cycles within software and systems discussions focus on ''project'' life cycles. See, for example, the ''Software Extension to PMBOK Guide'' (PMI 2013).<br />
<br />
==System of Systems Context in EIT==<br />
“Enterprise IT” (EIT) is used both to refer to the technology organization/business unit within the enterprise and to the enterprise’s information technology systems. In this article, we use EIT to refer to the technology systems. When referring to the organization, we use the phrase “Enterprise IT organization” or EIT organization. <br />
<br />
Enterprise IT organizations are responsible for complex socio-technical systems. Socio-technical systems in a business context (thus, EIT) contain technical elements (software, hardware, networks, storage, databases, etc.) but they also contain essential human components and necessary business processes. As covered in [[Introduction to Systems Engineering Fundamentals]], they exist in an engineered System Context that is a set of system component interrelationships within a real-world environment:<br />
<br />
This includes where problems come from and how they are defined, how we identify and select candidate solutions, how to balance technology and human elements in the wider solution context, how to manage the complex organizational systems needed to develop new solutions, and how developed solutions are used, sustained and disposed of. … Systems Engineering should consider the full Engineered System Context so that the necessary understanding can be reached and the right systems engineering decisions can be made. <br />
<br />
Socio-technical systems also have the following key characteristics: ''Openness'' in that they strongly interact with their environments, and ''unfinished'' in that they evolve over time.<br />
A complex of EIT systems is essential to the successful functioning of the humans in the enterprise. They rely on EIT’s technology for communication, for paying employees, for people management, for business measurement, and often for managing supply chains. Thus, “EIT needs to be viewed as a strategic partner to all the other functions and business units within an enterprise. This means that the results produced by EIT along with its effectiveness and efficiency are all critically important to the success of the enterprise.” [http://eitbokwiki.org/What_is_the_Enterprise_Perspective%3F]<br />
<br />
To accomplish this mission, the EIT organization builds and acquires new systems or system components, integrates them into the mega System of Systems, and maintains the integrity and interoperability of the individual components, but also the integrity of the entire complex of systems. In addition, security and performance levels must be achieved, benchmarked and maintained or improved.<br />
<br />
==Major concerns of the EIT Organization==<br />
The [http://eitbokwiki.org ''Enterprise IT Body of Knowledge''] provides a good deal of information about these major concerns, which we will not replicate here. Rather, links to the relevant areas are provided. The EITBOK demonstrates how, in providing technology systems and services to the enterprise, the EIT organization must skillfully manage such concerns as the following.<br />
<br />
===Enterprise Architecture===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Enterprise_Architecture Enterprise Architecture] for additional information. ''<br />
<br />
[http://eitbokwiki.org/Glossary#ea ''Enterprise architecture''] (EA) is the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. EA applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their organization's strategies. Enterprise architecture builds upon many of the concepts and practices of [[System Architecture Definition|systems architecture]] and also software architecture [https://www.sebokwiki.org/wiki/System_Architecture_Definition].<br />
<br />
This section will discuss Enterprise Architecture from the perspective of key [[Principles of Systems Thinking]], designated in this article with '''''bold italics'''''. There are many commonalities in architecture whether one is architecture systems, software or the enterprise [Unity]. In this article we highlight both commonalities and differences between Enterprise Architecture and Systems Architecture. <br />
<br />
Architecture takes place at the juncture of design problems and their solutions. Design problems rarely arrive fully formulated or “hatched” for the architect; much of the architecture effort is to analyze or formulate the problems to be solved. Often this involves negotiation both within the enterprise and with outside stakeholders. Possible solutions are limited by resources and schedule and therefore often must also be negotiated.<br />
<br />
A dominant principle of Enterprise Architecture is '''''separation of concerns''''' (SoC). This is due to the complexity of enterprises, with many forces acting upon them; the many technologies and disciplines involved in their creation and day-to-day operations; and due to the diversity of stakeholders involved in the enterprise (see [[EIT Roles]]). <br />
<br />
An application of SoC is the '''''boundary''''' principle which is crucial to separate what is “inside” the enterprise from what is “outside”. While the former is often under the enterprise’s control, the latter is often beyond its control. <br />
<br />
For some systems, determining the boundary is a key decision, subject to many possibilities and consequences. This is perhaps less the case for enterprises whose bounds are determined by the extent of organizations, regulations, supply chains or other criteria. Within an established boundary, the '''''holism''''' principle applies: to treat the enterprise as a unified whole, and, in particular, with respect to the '''''interaction''''' of the enterprise with its ''environment''—including stakeholders, other enterprises and systems. From an enterprise IT perspective, an enterprise is a ''system of systems. '' SoC offers a way to focus on the constituent systems in terms of their interconnections to one another to form the enterprise.<br />
<br />
Another useful application of SoC is to apply the principle of '''''multiple views''''' to depict the architecture of the enterprise in different ways to address the diverse interests (i.e., ''concerns'') of an enterprise’s various stakeholders. Each ''architecture view'' presents a specific perspective on the enterprise. To be understandable to its audiences (those various stakeholders), each view should follow the conventions of its ''architecture viewpoint'' (ISO/IEC/IEEE 42010 2011). Just as a map should have a legend, each view should have a documented viewpoint providing a prescribed set of conventions for looking at the enterprise through the resulting view. A viewpoint definition serves as a contract between the architect and stakeholders on ''how'' a selected set of concerns are to be addressed. Each viewpoint allows the architect to consider the enterprise in terms of various kinds of elements and relations among them and to present that view to those “concerned” stakeholders. Dominating concerns in enterprise architecture include interoperability, quality of systems and services, operations, managing change, and alignment with the enterprise’s mission, market, and technology. Via the principle of '''''dualism''''', we recognize that some viewpoints are paired, such as with process/data duality. Another pervasive duality in the enterprise is of people/technology in terms of what capabilities are automated and which are performed by people.<br />
<br />
In support of enterprise architecture, there are numerous ''enterprise architecture frameworks'' each providing a pre-defined, integrated set of viewpoints to frame typical, recurring concerns (ISO/IEC/IEEE 42010 Users Group 2022). The earliest recorded framework was (Hammer et al. 1986), developed in the mid-1980s in response to growing availability of distributed computing to the enterprise (Rivera 2013). In the late 1980s, US NIST created its Enterprise Architecture Model as a guide for US federal departments to organize their IT offerings (Fong and Goldfine 1989). NIST’s 5-layer model remains influential today. Despite never using the term “enterprise,” Zachman’s information systems architecture has had a major influence on how subsequent frameworks have been organized and depicted using grids or cubes. Later frameworks have evolved in response to emerging concepts, such as the move from client-server to service-oriented applications, as in the OASIS SOA Reference Model and its associated framework. The 1990s saw a proliferation of frameworks for defense enterprises including US DODAF, UK MODAF, NATO’s NAF and led to successors such as OMG’s UAF.<br />
<br />
Yet another application of '''''separation of concerns''''' is distinguishing today’s needs versus facilitating future needs; balancing '''''stability/change''''' and highlighting the temporal planning aspect of architecture of the enterprise. In concert with applying SOC, the architect uses the principle of '''''abstraction''''' to “forget” some details of the subject and thus focus on essentials. Just as SoC is a way of taking things apart, '''''abstraction''''' is a way of unifying or putting like things together through generalization. These two principles are perhaps the most central to architecture. SoC and abstraction work together: SoC picks out subjects and abstraction helps architects to focus upon the essentials of each subject. <br />
<br />
Returning to the '''''boundary''''' and '''''holism''''' principles, the enterprise architect applies these recursively. As architecting proceeds, the internal details of the enterprise become known in terms of '''''interaction''''' among its parts and other '''''relations'''''. Again, '''''multiple views''''' are used to factor specific '''''relations'''''into distinct views. Typical relations include Causality, Dependency, Client-Server, and Input-Output. <br />
<br />
There are a variety of ways to structure the enterprise based upon stakeholder needs, mission or charter, technologies or capabilities already in place. Among these are structuring principles including: <br />
* '''''Modularity''''' (separate and group capabilities into modules by commonalities); <br />
* '''''Network''''' (modules are linked together); <br />
* '''''Encapsulation''''' (separating architecture modules use from how they are implemented); <br />
* '''''Layer Hierarchy''''' (separation through gradual refinement); <br />
* ''''' Regularity''''' (uniformity of interactions, of structure within layer, within network). <br />
* ''''' Similarity/Difference''''' (recognizing the limits of Regularity)<br />
<br />
A simple pattern for architecture has been defined (Hofmeister ''et al. '' 2007). Its elements are Analysis, Synthesis and Evaluation. See Figure 1 below. <br />
<br />
''Architecture Analysis'' formulates architecturally-significant requirements (ASRs)—those requirements which influence an enterprise’s architecture. Architecture analysis is based on identified concerns and other information based on understanding the enterprise’s environment, known requirements, stakeholder needs and any constraints. ASRs reflect the “design problems” that the architecture must solve. In many cases, negotiations take place to modify incoming needs, requirements and expectations to make solutions possible. The result of this activity takes the form of ASRs, including architecture principles and initial enterprise-wide decisions.<br />
<br />
''Architecture Synthesis'' develops candidate solutions in response to the concerns and ASRs. During Synthesis the architect works out the details of solutions to the identified design problems, tradeoff and interactions between them which are likely to generate further design problems. Synthesis elaborates the ASRs, principles and initial decisions into more detailed solution elements. The principle of ''''' EQUIFINALITY''''' reminds us that for many stable situations (i.e., states of the enterprise), there are many ways to reach those states.<br />
<br />
''Architecture Evaluation'' validates whether chosen solutions satisfy ASRs or whether rework is needed (ISO/IEC/IEEE 42030 2019).<br />
<br />
Applying the principles discussed above is pervasive in enacting the Analysis–Synthesis–Evaluation pattern iteratively. <br />
<br />
[[File:EIT Figure 1 - Higher Resolution.png|centre|thumb|1000px|'''Figure 1. A pattern for Architecture.''']]<br />
<br />
While there are many commonalities among EIT, systems and software architectures, Figure 2 addresses the relationships ''between'' them. Viewing an enterprise as a system, the EIT architecture governs the fundamental IT decisions of the enterprise. That enterprise might be extended to “outsiders” such as vendors, suppliers and perhaps customers. Depending upon the enterprise, the ''governs'' relationship may entail very strict rules or loose guidance. <br />
Within the enterprise, the ecosystem of systems, applications and data may be viewed as a system of systems. The EIT Architecture constrains the architectures governing individual systems, applications and data stores within the enterprise, so that these are able to interoperate and otherwise “play nicely” together.<br />
<br />
[[File:EIT Figure 2.png|centre|thumb|1000px|'''Figure 2. Relating Enterprise IT, Systems and Software Architecture.''']] <br />
<br />
===Strategy and Governance===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance] for additional information. ''<br />
<br />
<blockquote><br />
[http://eitbokwiki.org/Glossary#eit Enterprise information technology] (EIT) governance is the established process of defining the strategy for the EIT organization and overseeing its execution to achieve enterprise goals. Strategic planning translates the larger enterprise’s goals into EIT goals and defines what EIT must do to achieve those goals. This effort then communicates this hierarchy of goals: EIT goals as well as how they support the enterprise’s goals. EIT governance drives needed changes to achieve those goals, while maintaining agreed levels of operation. Taking into account various perspectives (such as financial, historical, environmental, and future projections), a strategic plan is a roadmap for action and change, both vertically and horizontally, across the EIT organization. The EIT organization’s strategic plans are based on the enterprise’s strategic plans, focusing on EIT’s role in them; EIT governance provides a monitoring and control framework to achieve strategic goals and objectives. Thus, EIT governance is essential for achieving the EIT strategy and goals..<br />
-[http://eitbokwiki.org/Strategy_and_Governance EITBOK wiki]<br />
</blockquote><br />
<br />
The principle of ''''' PARSIMONY''''' applies here, too (see [[Principles of Systems Thinking]]). These principles will be designated in this article with '''''bold italics'''''. For example, the simplest possible measurement and reporting systems are most likely to be used and not corrupted. Similarly, the EIT organizational structure should be straightforward and easy to traverse so that staff can communicate and problem-solve in teams.<br />
In governing the EIT organization to meet its dual goals of satisfying its customers and meeting its budget and schedule commitments, EIT management encounters the difficulty of managing in the face of '''''dualism''''', “ensuring a constant dynamic balance often through a cyclic dominance of one element and then the other”. The most obvious instance of handling ''''' dualism''''' in EIT is the trade-off between budget, project prioritization and features within projects.<br />
<br />
===Change===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Change_Initiatives Change Initiatives] for more information. ''<br />
<br />
There are two levels of change management discussed in the EITBOK: organizational change management and changes to the IT organization’s assets, whether they be software, hardware, or telecommunications systems.<br />
In the larger sense, the introduction of new systems and services often also requires changes in people’s jobs and in the processes used to accomplish those jobs. Such efforts are intended to increase business value. Such changes require change initiatives because they involve guiding a mixture of stakeholders through the change process. This is one aspect of [http://eitbokwiki.org/Change_Initiatives change management].<br />
Change also occurs when existing systems or services must be updated to meet new needs. Depending on the scope of the proposed changes, a change initiative may be required in this situation, too. At any rate, a change request process must be initiated and tracked to disposition (deferral, rejection, or implementation). Changes also come about as a result of defect reports. In such cases, the defect report must be tracked throughout the report’s life cycle, to disposition (deferral, rejection, or implementation).<br />
<br />
These latter types of change management are discussed in detail in the EITBOK’s section on [http://eitbokwiki.org/Operations_and_Support Operations and Support].<br />
<br />
===Interoperability of Component Systems===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Interoperability interoperability] for more information. ''<br />
<br />
As explained in the [http://eitbokwiki.org/Interoperability#One EITBOK], ''interoperability'' means “the ability of systems (including organizations) to exchange and use exchanged information without knowledge of the characteristics or inner workings of the collaborating systems (or organizations).” This definition is based on an ISO definition: “degree to which two or more systems, products, or components can exchange information and use the information that has been exchanged.” (ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models, 4.2.3.2. ) Note that this definition includes hardware components as well as software systems and the organizations in which they are used.<br />
<br />
Because technology changes so rapidly, and organizations themselves are frequently changing, achieving and maintaining interoperability is crucial. It is one of the main reasons that providing IT services is difficult and how it differs from engineering and delivering finished products, whether off-the-shelf products or bespoke systems.<br />
<br />
===Security of Systems and Data===<br />
<blockquote><br />
There are only two types of companies: those that have been hacked, and those that will be.<br />
-FBI Director Robert Mueller, October 2012<br />
</blockquote><br />
<br />
<blockquote><br />
There are two kinds of big companies in the United States. There are those who've been hacked by the Chinese and those who don't know that they've been hacked by the Chinese<br />
-FBI Director James Comey, October 2014<br />
</blockquote><br />
''See the EITBOK’s section on [http://eitbokwiki.org/Security security] for additional information. ''<br />
<br />
While there are many definitions for security, most include the three dimensions of confidentiality, integrity, and availability (sometimes referred to as the [http://eitbokwiki.org/Glossary#ciatriad CIA triad]). As such, the primary goal of EIT security is to preserve the confidentiality, integrity, and availability of information and information systems. <br />
<br />
The principles behind an organization’s [http://eitbokwiki.org/Glossary#isms information security management system] (ISMS) should be to design, implement, and maintain a coherent set of policies, processes, and systems that keep the risks associated with its information assets at a tolerable level, and yet, manage the cost and inconvenience of said risk management. As such, the goals of EIT security are to:<br />
<br />
* Always understand the current risk tolerance of the enterprise with respect to information and device security.<br />
* Understand the security threats and potential damages to information, devices, and individuals.<br />
* Create and follow policies and procedures that keep cyberattack risk and damages at or below a tolerable level.<br />
* Effectively and efficiently detect and deal with<br />
[http://eitbokwiki.org/Security#One cyberattack incidents].<br />
<br />
Ensuring security in EIT has been made even more pressing and more difficult by the proliferation of mobile devices in enterprises and their ever-increasing use to conduct business. Increasingly, personal devices (Bring Your Own Device – BYOD) are used, accessing both corporate networks and public networks. The cost of [https://www.checkpoint.com/downloads/products/check-point-mobile-security-survey-report2013.pdf mobile security incidents] very easily can outweigh the cost of the mobile device itself. <br />
<br />
==Quality of Systems and Services==<br />
The Enterprise ''Information'' Technology organization has, since its origins, had as its primary responsibility the timely provision of information to the larger organization. The information is expected to be not only timely, but also accurate and relevant. While the EIT organization itself may not be responsible for creating the data, it is responsible for the physical and logical validity and [https://simplicable.com/new/data-integrity-vs-data-quality integrity of the data] that is used to construct information. It is for this reason that defining and using appropriate processes is essential to ensure high-quality operation, including the development or acquisition, implementation and integration of new or changed capabilities.<br />
<br />
The EITBoK details the quality concepts of:<br />
* How to approach measuring [http://eitbokwiki.org/Quality#Measuring_Quality Quality]<br />
* The importance of Quality in [http://eitbokwiki.org/Quality#Requirements_Management Requirements Management]<br />
* Understanding an organization’s [http://eitbokwiki.org/Quality#Quality_Capability Quality Capability]<br />
* The differences between [http://eitbokwiki.org/Quality#QMS_and_QC_vs._QA QMS, QC and QA]<br />
* Cost of Quality in [http://eitbokwiki.org/Quality#Technical_Debt_and_the_Cost_of_Rework Technical Debt and the Cost of Rework]<br />
<br />
==Disaster Preparedness==<br />
<br />
As explained in the [http://eitbokwiki.org/Disaster_Preparedness EITBOK], disaster preparedness and [http://eitbokwiki.org/Glossary#dr disaster recovery] (DR) support business-continuity planning and include planning for EIT resiliency, as well as recovery from adversity, so that critical business services affected are restored to a satisfactory working state within an [http://eitbokwiki.org/Glossary#acceptable acceptable] timeframe after an event.<br />
The EITBoK devotes a chapter to how the EIT organization and its parent must plan in advance for how it will provide sufficient organizational resilience to recover from disasters and return to normal operation as rapidly as possible.<br />
<br />
It provides the following examples of disasters and service interruptions that could occur and should be considered in prevention and recovery planning:<br />
These are examples of disasters:<br />
<br />
* Natural disaster affecting datacenters or EIT service operations (flood, fire, earthquake, wind)<br />
* Security breach resulting in a disaster (destruction of data, admin password changes, virus/malware installation, sabotage)<br />
* Usage error (accidental deletion, unplug/turn off system resulting in corruption)<br />
* Utility failure affecting datacenters (loss of power even after UPS)<br />
* Vendor failure (cloud provider security failure, oil spill)<br />
* Staffing issue (employment dispute/walkout, epidemic)<br />
These are examples of unpreparedness:<br />
* Requiring use of computers or printers when power is out<br />
* Requiring use of Internet when power or connectivity is out<br />
* Single point of knowledge/control for administration access<br />
* Lack of offsite backup storage<br />
* Lack of working restoration from backups<br />
* Lack of failover datacenters in separate locations<br />
* Undocumented or out-of-date documentation for system interfaces<br />
*Requiring use of phones that are out of power<br />
* Lack of designation of leaders in restoration efforts (who is in charge of restoring service and they know they are in charge)<br />
* In general, no cohesive, comprehensive EIT service restoration plan<br />
<br />
==Operations and Support of Delivered Systems and Services==<br />
[http://eitbokwiki.org/Operations_and_Support Operations and support activities] focus on maintaining an operation normal state in EIT environments, meaning that systems and processes execute according to expectations, with no surprises to users. This desired normal state requires the careful management of EIT assets and services via Operations, as well as of users via Support.<br />
<br />
Normal states can be disrupted either by the expected and planned transition of an asset, or by an unexpected event, be it as large as a disaster or by the discovery of a system defect. In the former case, the Disaster Recovery Plan is executed; in the latter, incident management kicks in when a system halts, or problem management is exercised when an operational system is not functioning as expected. The processes needed to ensure effective application of these complex functions is detailed in the [http://eitbokwiki.org/Operations_and_Support#Guiding_Principles Operations and Support Knowledge Area] within the EITBOK. <br />
<br />
ISO/IEC/IEEE 20000 may be used by any organization to develop and manage EIT operations, along with the current version of [https://www.servicenow.com ITIL].<br />
<br />
ITIL for many is the tool of choice for the operations and infrastructure side of IT, particularly for IT services. <br />
<br />
==Ethics==<br />
See the EITBOK’s section on [http://eitbokwiki.org/Ethics ethics] for additional information.<br />
<br />
Both the IEEE and ACM require their members to adhere to Codes of Ethics. See the [https://www.ieee.org/about/corporate/governance/p7-8.html IEEE Code of Ethics] and [https://www.acm.org/code-of-ethics ACM Code of Ethics and Professional Conduct]. Both of these can be downloaded freely. In addition, the IEEE Computer Society and the ACM worked together on the [https://dl.acm.org/action/downloadSupplement?doi=10.1145%2F265684.265699&file=acm-se-code-of-ethics.html Software Engineering Code of Ethics] (also available [https://dl.acm.org/doi/10.1145/265684.265699 here]).<br />
<br />
The organization should create an easily accessible Code of Ethics:<br />
* Ethical assertions should be documented and socialized in EIT in the form of a Code of Ethics, tied to the overall business code of ethics, and signed off by all staff so that violations can be cause for reprimand or dismissal.<br />
* Vendors should be held to similar ethical standards.<br />
* Lists of employees who have signed off on the Code of Ethics are maintained by EIT governance.<br />
The EITBOK has identified EIT ethical topics that include:<br />
* Those actions and decisions that may be illegal<br />
* Consideration of the social impact of the work at hand—if it will cause harm<br />
* Alignment of business and EIT strategies and policies to an ethical standard<br />
* Incorporation of the ideals of professionalism<br />
* Adherence to applicable regulatory intent<br />
* Protection for whistle blowers<br />
Areas to specifically highlight:<br />
* Activities that interfere with or corrupt the proper function of computers, applications and systems<br />
* Activities that interfere with digital privacy or intellectual rights of others<br />
* Respect for confidentiality, privacy, permissions, and access rights<br />
* Inappropriate bias (skewing) of analysis and reporting<br />
* Inaction in the face of likely ethics violations<br />
<br />
==EIT Roles==<br />
Several roles play a part in accomplishing the EIT organization’s mission. Just as a systems engineer can play several roles in a given project, so might several people in an EIT project combine to fulfill the systems engineering function. <br />
<br />
The function of EIT systems engineering is to orchestrate systems development, delivery and operation such that the larger organization achieves favorable outcomes in complex environments. Unlike systems projects that are built for known problems, EIT systems may change in unpredictable ways. A primary concern focuses on how quickly systems adapt to change. This entails a type of resiliency based on skills in establishing options and alternative solutions as well as strategies tailored to the volatility of changing needs and available technologies. It also requires expertise in assuring that systems quality is assured from the start.<br />
Different countries, geographic areas and organizations do not always use the same terminology to reference the functions that the roles contributing to systems engineering perform. The following section will provide information about some major international models for defining EIT skills and capabilities. Generally, though, the necessary roles across the product life cycle include these:<br />
* Business Sponsor/Champion<br />
* Enterprise Architect<br />
* Systems Engineer<br />
* Financial Manager<br />
* Application Architect<br />
* Business Analyst and/or Process Analyst<br />
* Data Analyst and/or Data Architect<br />
* Software Engineer and/or Programmer<br />
* Quality Assurance & Testing<br />
* Network Engineer<br />
* Telecoms Engineer<br />
* Integration Expert <br />
* Transition to Operations Manager<br />
* Release Manager<br />
* Availability Manager<br />
* Capacity Manager<br />
* Change Manager<br />
* Configuration Manager<br />
* EIT Operations Manager<br />
* Incident Management<br />
* Problem Manager<br />
* Service Level Manager<br />
* Database Administrator<br />
* Network Manager<br />
* Product Manager<br />
<br />
System engineering activities orchestrate the work of these roles so that they function together, rather than in silos or at cross purposes.<br />
<br />
==Examples of Systems Engineering in EIT==<br />
Systems Engineering provides a holistic discipline for integrating and managing the contributions of all roles needed to establish and provide EIT products and services. It ensures that a single perspective does not dominate outcomes; instead, it seeks balance among the many disciplines represented above in creating a consistent product or service that meets the interests and needs of enterprise users (and, perhaps, partners). It boils down to common sense, technical sense, knowing when to ask the right questions, and getting the data to support the answers to those questions. System Engineering achieves this via Systems Engineers. In many instances, though, the SE function is accomplished through Project Management approaches using Integrated Product Teams that include technical experts. Thus, although not specifically calling out a Systems Engineering function, the use of IPTs involved the use of SE practices.<br />
<br />
A doctoral dissertation from Purdue University performed a survey and causal analysis of project failures and of accidents(Aloisio, 2018). The results were similar to those found in reviews of IBM consulting projects in the 1990s. The following are examples of Systems Engineering interventions that prevented project failures. Almost all point to the lack of the System Engineering balancing act needed for product delivery.<br />
<br />
* A widely used document processing product was undergoing a major upgrade. The new VP of Engineering wanted a project review before committing to a schedule. The review showed that the proposed schedule only considered the development effort and did not give sufficient weight to the voices of the testing and documentation organizations, while the needs of the tech support group had been completely overlooked. By establishing an integrated product management team that included technical expertise, as well as expertise in work breakdown and estimating, a realistic effort was defined and the resulting 9-month schedule was met within 3 weeks.<br />
* A Silicon Valley start-up was depending entirely on an offshore development effort to produce its first product. All senior management was in the U.S. The VP of engineering made monthly visits to the development team. The CEO began to feel uneasy about the team’s ability to deliver on schedule sensing that a lot of finger pointing within the development team itself signaled problems. There was no SE or IPT guiding the project. The VP of Engineering seemed unable to sort things out. A project review showed that the probable delivery date was at least 6 months beyond what the CEO was being told. The project was shut down.<br />
* A major player in Human Resource Management had made commitments to deliver a new product. The project involved more than 100 people across the U.S. The delivery date kept slipping. Project roll-out would involve both installation of software and hardware at client sites, as well as installation and staff training at the large, centrally located Client Services organization. Executive Management needed to decide whether to reorganize this very expensive effort or cancel it. Again, the successful solution depended on establishing an effective cross-functional team (IPT) that necessarily included representatives from the technical teams. The IPT was supported by a newly established Project Management Office (PMO). The PMO integrated the geographically disparate efforts by establishing communication channels, as well as common estimating and scheduling practices. The PMO also instituted monthly critical metrics reports to show the IPT bottlenecks and inefficiencies across the project, from development efforts to Client Services set-up to Payroll technical support.<br />
There are far more examples of the lack of systems engineering practices in EIT projects than in their successful use (unfortunately, this seems also to be true in lots of software projects outside of EIT). Systems Engineering provides a holistic discipline for integrating and managing the contributions of all of the roles needed to provide EIT products and services. It ensures that a single perspective does not dominate outcomes.<br />
<br />
==Key External Models of EIT Organizational Capability and Maturity==<br />
Because EIT is critical to businesses globally, considerable effort has gone into establishing universal frameworks for EIT skills, along with definitions of levels of capability of each skill. In addition, at least 2 models have been developed for evaluating the organizational performance of EIT. The effectiveness of systems engineering is key to the effectiveness of the EIT organization.<br />
<br />
===IT-CMF: IT-Capability Maturity Framework=== <br />
The IT-CMF had its origin in a quality improvement effort at Intel Labs Europe in Ireland. Its intent, as described at the <br />
[https://cio-wiki.org/wiki/IT_Capability_Maturity_Framework_(IT-CMF) CIO Index website] was to quantify and demonstrate the true value impact of IT. IT-CMF is used to measure, develop, and monitor an organization’s EIT capability maturity. It consists of 35 EIT management capabilities organized into four macro capabilities: managing EIT like a business; managing the EIT budget; managing the EIT capability; and managing EIT for business value. Its 35 critical capabilities (CCs) are [http://eitbokwiki.org/Enterprise_IT_Maturity_Assessment described] as “A defined EIT management domain that helps mobilize and deploy EIT-based resources to effect a desired end, often in combination with other resources and capabilities”. <br />
<br />
===CMMI: Capability Maturity Model Integration (US)===<br />
The CMMI had its origin in 1987 in a model requested by the U.S. Department of Defense for determining the capability maturity of contractor software development organizations. This became the Capability Maturity Model (CMM). Since then, it has been expanded into a set of Capability Maturity Models, all based on five levels of demonstrably increasing maturity as measured by organization performance. That set was then integrated and became the CMMI. The CMMI set addresses [https://cmmiinstitute.com/dev Development], [https://cmmiinstitute.com/svc Services], [https://cmmiinstitute.com/sm Supplier Management], [https://cmmiinstitute.com/pm People Management], and [https://cmmiinstitute.com/dm Data Management].<br />
<br />
===SFIA: Skills Framework for the information Age (Europe, Canada and US)===<br />
The SFIA Framework has been downloaded and used by organizations and individuals in nearly 180 countries. It can be downloaded for free at [https://www.sfia-online.org]. It identifies 97 professional skills across EIT and supporting areas with seven levels of responsibility, which provide generic levels of responsibility, taking into account reflect experience and competency. These describe the behaviors, values, knowledge, and characteristics that an individual should have in order to be considered competent at a particular level.<br />
<br />
===E-CF: European Competency Framework (EU)===<br />
The ECF was the first sector-specific implementation of the European Qualifications Framework (EQF). The European Norm (EN) 16234-1 European e-Competence Framework (e-CF) provides a reference of 41 competences as applied at the Information and Communication Technology (ICT) workplace, using a common European reference for competences, skills, knowledge and proficiency levels. The E-CF Explorer web tool is available [https://ecfexplorer.itprofessionalism.org/ online].<br />
<br />
===I Competency Dictionary: EIT skills as Defined by METI/ IPA (Japan)===<br />
The Japanese government’s Information-Technology Promotion Agency (IPA), established by the Ministry of Economy, Trade and Industry (METI) developed the ”I Competency Dictionary” (iCD) to support the IT Engineers Examination. It underlies the METI/IPA Skills Standards for IT Professionals, abbreviated as ITSS, established in 2002. ITSS organizes skills within the information services industry into 11 job categories and 35 specialty fields. In each field, there are seven levels of competence based on individual experience and ability to perform. One appealing feature of ITSS is that this standard allows engineers to draw roadmaps for their own futures and career advancement (Career Path). Approximately 90% of large enterprises and over 60% of SMEs in Japan have introduced or are considering using ITSS. Information in English is available at https://www.ipa.go.jp/english/humandev/forth.html.<br />
<br />
===ITIL: Information Technology Infrastructure Library===<br />
According to ITLIlibrary.org, the ITIL Open Guide website, “The Information Technology Infrastructure Library (ITIL) defines the organisational structure and skill requirements of an information technology organisation and a set of standard operational management procedures and practices to allow the organisation to manage an IT operation and associated infrastructure. … The [https://www.itlibrary.org/ “library”] itself continues to evolve. This comprises five distinct areas: <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Strategy ITIL Service Strategy]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Design ITIL Service Design]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Transition ITIL Service Transition]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Operation ITIL Service Operation]; and <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Continual_Service_Improvement ITIL Continual Service Improvement].”<br />
It originally grew out of a British government sponsored effort to regularize IT Service Management (ITSM). <br />
<br />
==References==<br />
===Works Cited===<br />
Fong, E.N. and A.H. Goldfine. 1989. ''Information Management Directions: The Integration Challenge. '' National Institute of Standards and Technology (NIST) Special Publication 500-167, September 1989. https://csrc.nist.rip/library/NIST%20SP%20500-167.pdf <br />
<br />
Hammer, M., T.H. Davenport and J. Champy. 1986. ''Dispersion and Interconnection: Approaches to Distributed Systems Architecture'', Cambridge, MA: CSC Index Inc. and Hammer and Company, Inc. (June 1986). Available as: https://www.globalaea.org/general/custom.asp?page=Resources <br />
<br />
Hilliard, R. 2015. “Lessons from the fundamental unity of architecting”. ''Software Engineering in the Systems Context'', editors: Ivar Jacobson and Harold 'Bud' Lawson.<br />
<br />
Hofmeister, C. et al. 2007. “A general model of software architecture design derived from five industrial approaches”. ''The Journal of Systems and Software'' 80(1). <br />
<br />
ISO/IEC 25010:2011 ''Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models'', 4.2.3.2.<br />
<br />
ISO/IEC/IEEE 42010 Users Group. ''Survey of Architecture Frameworks'' Available as: http://www.iso-architecture.org/42010/afs/<br />
<br />
ISO/IEC/IEEE. 2011. ISO/IEC/IEEE 42010:2011, ''Systems and software engineering — Architecture description. ''<br />
<br />
PMI. 2013. ''Software Extension to PMBOK® Guide – Fifth Edition. '' Newtown Square, PA, USA: Project Management Institute (PMI). Available as: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/software-extension-5th-edition.<br />
<br />
Rivera, R. 2013. “The PRISM Architecture Framework – Was it the Very First Enterprise Architecture Framework?” ''Journal of Enterprise Architecture'', November 2013<br />
<br />
Zachman, J. 1987. “A Framework for Information Systems Architecture”. ''IBM Systems Journal'', pp454-470, 1987 <br />
<br />
===Primary References===<br />
IEEE Computer Society. ''Enterprise IT Body of Knowledge''. Available: http://eitbokwiki.org<br />
<br />
=-=Additional References===<br />
IT Capability Maturity Framework (IT-CMF): The Body of Knowledge Guide. 2015. Editors. Martin Curley, Jim Kenneally, Marian Carcary. Van Haren Publishing.<br />
<br />
Lessons from Systems Engineering Failures: Determining Why Systems Fail, The State of Systems Engineering Education, and Building an Evidence-Based Network to Help Systems Engineers Identify and Fix Problems on Complex Projects, Diane Constance Aloisio, December 2018.<br />
<br />
===International Standards Guiding EIT===<br />
ANSI/AIAA. 2012. ''ANSI/AIAA Guide to the Preparation of Operational Concept Documents. '' ANSI/AIAA G-043A-2012e.<br />
<br />
IEEE 2012 Std 828™-2012, ''IEEE Standard for Configuration Management in Systems and Software Engineering. ''<br />
<br />
ISO 10004:2012, Quality management—Customer satisfaction—Guidelines for monitoring and measuring<br />
<br />
ISO 10007:2003, Quality management systems—Guidelines for configuration management<br />
<br />
ISO 18238:2015, Space systems—Closed loop problem solving management<br />
<br />
ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models<br />
<br />
ISO/IEC 16350:2015, Information technology—Systems and software engineering—Application management<br />
<br />
ISO/IEC 19770-1:2012, Information technology—Software asset management—Part 1: Processes and tiered assessment of conformance<br />
<br />
ISO/IEC 20000-1:2011, (IEEE Std 20000-1:2013) Information technology—Service management—Part 1: Service management system requirements<br />
<br />
ISO/IEC 20000–2:2012, Information technology—Service management—Part 2: Guidance on the application of service management systems<br />
<br />
ISO/IEC TR 20000–10:2015, Information technology—Service management—Part 10: Concepts and terminology<br />
<br />
ISO/IEC TR 20000–11:2015, Information technology—Service management—Part 11: Guidance on the relationship between ISO/IEC 20000-1:2011 and related frameworks: ITIL®<br />
<br />
ISO/IEC TR 20000-12—Information technology—IT Service management—Part 12: Guidance on the relationship between ISO/IEC 20000-1:2011 and service management frameworks: CMMI-SVC®<br />
<br />
ISO/IEC/IEEE 14764-2006, Software Engineering—Software Lifecycle Processes—Maintenance<br />
<br />
ISO/IEC 15939:2007, Systems and software engineering—Measurement process<br />
<br />
ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description <br />
<br />
<br />
----<br />
<center>[[ Systems Engineering and Economics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Quality Attributes|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Enterprise_IT&diff=66944
Systems Engineering and Enterprise IT
2023-05-07T04:03:10Z
<p>Mhaas: </p>
<hr />
<div>----<br />
'''''Lead Authors:''''' Chuck Walrad and Richard Hilliard<br />
----<br />
This article forms part of the [[Related Disciplines]] knowledge area (KA). It discusses enterprise IT, building upon the concepts and practices of Systems Engineering presented elsewhere in the SEBOK. Systems Engineering is integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of ''engineered technical systems''. <br />
<br />
== Enterprise IT Introduction==<br />
Although it had its origin in the need to improve success rates in U.S. Government outsourcing of technical systems, Systems Engineering is also integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of [https://www.incose.org/about-systems-engineering/system-and-se-definition/systems-engineering-definition#ENGINEERED_SYSTEM engineered technical systems].<br />
Examples of EIT systems include enterprise resource planning, supply chain management and customer relationship management systems, accounting, finance, inventory and order management, marketing, planning, purchasing, and sales.<br />
In the late 1980s and throughout the 1990s, EIT organizations became increasingly aware that the success rates of IT projects were very low, and that their enterprise customers were increasingly unhappy with their EIT investments. The Standish Group sought to understand what was going on. Their findings were presented in the [https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf Chaos Report] (1994):<br />
The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable but could easily be in the trillions of dollars.<br />
As a result, commercial IT organizations, through the auspicious parallel emergence of the Total Quality Management movement and the increasingly widespread development of application development methodologies (ADM) by IT management consulting firms, recognized the need for the principles of Systems Engineering and cross-functional teams (Integrated Product Teams [https://www.sebokwiki.org/wiki/Integrated_Product_Team_(IPT)_(glossary)]. It should be noted that there is considerable overlap today between what constitutes Systems Engineering and what constitutes [[Portfolio Management|Relationships between Systems Engineering and Project Management]] (see [https://www.pmi.org/learning/library/bridging-gap-program-management-systems-engineering-6213 PMI]). This article does not attempt to resolve this issue. Note that the “[[Related Business Activities|following business management activities]] can be ''supported'' by enterprise systems engineering (ESE) activities” [emphasis added]: <br />
* mission and strategic planning,<br />
* business processes and information management,<br />
* performance management,<br />
* portfolio management,<br />
* resource allocation and budgeting, and<br />
* program and project management.<br />
Note that these same areas have been designated as being supported by Project Management Offices. However, since a key difference between project management and systems engineering has been identified as the requirement that the latter includes technical expertise in the product/system of concern, focus should be on systems engineering and integrated product teams (IPTs). <br />
With IPTs, each product is shepherded from concept through delivery and support to retirement by a cross-functional team that includes representatives from each area of responsibility, such as customer requirements development, design and development, test, configuration management, release engineering, delivery, and support.<br />
As enterprises have come to depend more and more on technology to perform effectively, Enterprise IT organizations have matured, often due to the influence of IT consulting firms that make it their business to keep abreast of best practices.<br />
<br />
== EIT Concepts ==<br />
This knowledge area (KA) discusses enterprise IT, building upon the concepts elucidated in the IEEE/ACM ''[http://eitbokwiki.org EITBOK Guide to the Enterprise Information Technology Body of Knowledge]'' and general concepts of Systems Engineering elsewhere in SEBOK. <br />
An enterprise may be viewed from various perspectives: such as a system or a [[Enterprise Systems Engineering|system of systems (SoS)]]:<br />
* system-like enterprise: enterprises, like other systems, may have a tight coupling, single-executive function; <br />
* system of systems-like enterprise: may be a loosely coupled group of organizations with blurred boundaries and (yet) with (some) shared outcomes.<br />
The choice of perspective may vary with many factors: the enterprise itself, the mission or purpose, or the particular engineering task at hand. We can view an enterprise as a system with inputs and outputs in relation to the outside world, or a system of systems interacting through their individual inputs and outputs. <br />
An enterprise usually involves one (or more) organization(s) but need not be identified with the organization. As the scope of human and organizational participants of the enterprise widen, there may be no single point of control. For example, an ''extended enterprise'' could include a company, its suppliers and customers.<br />
Whatever perspective (system-like, SoS-like, other) is taken there are [[Enterprise Systems Engineering Background|key ingredients]] of any enterprise: capabilities, individual (competencies) and the organizational design. [[Enterprise Capability Management|Capabilities]] can be further categorized: “There are three different kinds of capability: organizational capability, system capability, and operational capability.” These capabilities determine what the enterprise is able to produce which may be external offerings or internal mechanisms. Operational capabilities create services and/or products which in turn produce value as determined by stakeholders. The capabilities of an enterprise are realized through [[Enterprise Systems Engineering Background|various enterprise elements]], including: “hardware, software, personnel, facilities, data, materials, techniques, and even services”. which include “soft” items, like people, processes, principles, policies, practices, organizations, doctrine, theories, and beliefs.<br />
EIT capabilities exist through lifecycles spanning from creation through eventual replacement and disposal. ''Life cycle models'' are schemes to aid in the understanding, design, planning and management of the capability of interest. <br />
“A life cycle for a system generally consists of a series of stages regulated by a set of management decisions which confirm that the system is mature enough to leave one stage and enter another.” Basic life cycle terms and concepts are discussed in [[Systems Lifecycle Approaches]]. Some typical life cycles are discussed in [[System Lifecycle Models]].<br />
A life cycle-based approach can be deployed across the several levels and used to manage evolution. These levels are:<br />
* the enterprise itself,<br />
* the processes and organizations constituting the enterprise,<br />
* the systems enabling the capabilities, services or products provided. <br />
It is important to distinguish between ''product'' and ''project'' lifecycle models. A product’s life cycle extends from its initial concept approval, through development and distribution, to its retirement. This is the cycle that is managed within an Enterprise IT organization, since EIT must manage the hardware or software product from its introduction, in the case of acquired capabilities, or from its concept approval and development, in the case of capabilities it builds, through its deployment, maintenance and eventual retirement (withdrawal). Each of these stages is usually managed as a project or a series of projects.<br />
However, most discussions of life cycles within software and systems discussions focus on ''project'' life cycles. See, for example, the ''Software Extension to PMBOK Guide'' (PMI 2013).<br />
==System of Systems Context in EIT==<br />
“Enterprise IT” (EIT) is used both to refer to the technology organization/business unit within the enterprise and to the enterprise’s information technology systems. In this article, we use EIT to refer to the technology systems. When referring to the organization, we use the phrase “Enterprise IT organization” or EIT organization. <br />
Enterprise IT organizations are responsible for complex socio-technical systems. Socio-technical systems in a business context (thus, EIT) contain technical elements (software, hardware, networks, storage, databases, etc.) but they also contain essential human components and necessary business processes. As covered in [[Introduction to Systems Engineering Fundamentals]], they exist in an engineered System Context that is a set of system component interrelationships within a real-world environment:<br />
This includes where problems come from and how they are defined, how we identify and select candidate solutions, how to balance technology and human elements in the wider solution context, how to manage the complex organizational systems needed to develop new solutions, and how developed solutions are used, sustained and disposed of. … Systems Engineering should consider the full Engineered System Context so that the necessary understanding can be reached and the right systems engineering decisions can be made. <br />
Socio-technical systems also have the following key characteristics: ''Openness'' in that they strongly interact with their environments, and ''unfinished'' in that they evolve over time.<br />
A complex of EIT systems is essential to the successful functioning of the humans in the enterprise. They rely on EIT’s technology for communication, for paying employees, for people management, for business measurement, and often for managing supply chains. Thus, “EIT needs to be viewed as a strategic partner to all the other functions and business units within an enterprise. This means that the results produced by EIT along with its effectiveness and efficiency are all critically important to the success of the enterprise.” [http://eitbokwiki.org/What_is_the_Enterprise_Perspective%3F]<br />
To accomplish this mission, the EIT organization builds and acquires new systems or system components, integrates them into the mega System of Systems, and maintains the integrity and interoperability of the individual components, but also the integrity of the entire complex of systems. In addition, security and performance levels must be achieved, benchmarked and maintained or improved.<br />
==Major concerns of the EIT Organization==<br />
The [http://eitbokwiki.org ''Enterprise IT Body of Knowledge''] provides a good deal of information about these major concerns, which we will not replicate here. Rather, links to the relevant areas are provided. The EITBOK demonstrates how, in providing technology systems and services to the enterprise, the EIT organization must skillfully manage such concerns as the following.<br />
<br />
===Enterprise Architecture===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Enterprise_Architecture Enterprise Architecture] for additional information. ''<br />
[http://eitbokwiki.org/Glossary#ea ''Enterprise architecture''] (EA) is the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. EA applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their organization's strategies. Enterprise architecture builds upon many of the concepts and practices of [[System Architecture Definition|systems architecture]] and also software architecture [https://www.sebokwiki.org/wiki/System_Architecture_Definition].<br />
This section will discuss Enterprise Architecture from the perspective of key [[Principles of Systems Thinking]], designated in this article with '''''bold italics'''''. There are many commonalities in architecture whether one is architecture systems, software or the enterprise [Unity]. In this article we highlight both commonalities and differences between Enterprise Architecture and Systems Architecture. <br />
Architecture takes place at the juncture of design problems and their solutions. Design problems rarely arrive fully formulated or “hatched” for the architect; much of the architecture effort is to analyze or formulate the problems to be solved. Often this involves negotiation both within the enterprise and with outside stakeholders. Possible solutions are limited by resources and schedule and therefore often must also be negotiated.<br />
A dominant principle of Enterprise Architecture is '''''separation of concerns''''' (SoC). This is due to the complexity of enterprises, with many forces acting upon them; the many technologies and disciplines involved in their creation and day-to-day operations; and due to the diversity of stakeholders involved in the enterprise (see [[EIT Roles]]). <br />
An application of SoC is the '''''boundary''''' principle which is crucial to separate what is “inside” the enterprise from what is “outside”. While the former is often under the enterprise’s control, the latter is often beyond its control. <br />
For some systems, determining the boundary is a key decision, subject to many possibilities and consequences. This is perhaps less the case for enterprises whose bounds are determined by the extent of organizations, regulations, supply chains or other criteria. Within an established boundary, the '''''holism''''' principle applies: to treat the enterprise as a unified whole, and, in particular, with respect to the '''''interaction''''' of the enterprise with its ''environment''—including stakeholders, other enterprises and systems. From an enterprise IT perspective, an enterprise is a ''system of systems. '' SoC offers a way to focus on the constituent systems in terms of their interconnections to one another to form the enterprise.<br />
Another useful application of SoC is to apply the principle of '''''multiple views''''' to depict the architecture of the enterprise in different ways to address the diverse interests (i.e., ''concerns'') of an enterprise’s various stakeholders. Each ''architecture view'' presents a specific perspective on the enterprise. To be understandable to its audiences (those various stakeholders), each view should follow the conventions of its ''architecture viewpoint'' (ISO/IEC/IEEE 42010 2011). Just as a map should have a legend, each view should have a documented viewpoint providing a prescribed set of conventions for looking at the enterprise through the resulting view. A viewpoint definition serves as a contract between the architect and stakeholders on ''how'' a selected set of concerns are to be addressed. Each viewpoint allows the architect to consider the enterprise in terms of various kinds of elements and relations among them and to present that view to those “concerned” stakeholders. Dominating concerns in enterprise architecture include interoperability, quality of systems and services, operations, managing change, and alignment with the enterprise’s mission, market, and technology. Via the principle of '''''dualism''''', we recognize that some viewpoints are paired, such as with process/data duality. Another pervasive duality in the enterprise is of people/technology in terms of what capabilities are automated and which are performed by people.<br />
In support of enterprise architecture, there are numerous ''enterprise architecture frameworks'' each providing a pre-defined, integrated set of viewpoints to frame typical, recurring concerns (ISO/IEC/IEEE 42010 Users Group 2022). The earliest recorded framework was (Hammer et al. 1986), developed in the mid-1980s in response to growing availability of distributed computing to the enterprise (Rivera 2013). In the late 1980s, US NIST created its Enterprise Architecture Model as a guide for US federal departments to organize their IT offerings (Fong and Goldfine 1989). NIST’s 5-layer model remains influential today. Despite never using the term “enterprise,” Zachman’s information systems architecture has had a major influence on how subsequent frameworks have been organized and depicted using grids or cubes. Later frameworks have evolved in response to emerging concepts, such as the move from client-server to service-oriented applications, as in the OASIS SOA Reference Model and its associated framework. The 1990s saw a proliferation of frameworks for defense enterprises including US DODAF, UK MODAF, NATO’s NAF and led to successors such as OMG’s UAF.<br />
Yet another application of '''''separation of concerns''''' is distinguishing today’s needs versus facilitating future needs; balancing '''''stability/change''''' and highlighting the temporal planning aspect of architecture of the enterprise. In concert with applying SOC, the architect uses the principle of '''''abstraction''''' to “forget” some details of the subject and thus focus on essentials. Just as SoC is a way of taking things apart, '''''abstraction''''' is a way of unifying or putting like things together through generalization. These two principles are perhaps the most central to architecture. SoC and abstraction work together: SoC picks out subjects and abstraction helps architects to focus upon the essentials of each subject. <br />
Returning to the '''''boundary''''' and '''''holism''''' principles, the enterprise architect applies these recursively. As architecting proceeds, the internal details of the enterprise become known in terms of '''''interaction''''' among its parts and other '''''relations'''''. Again, '''''multiple views''''' are used to factor specific '''''relations'''''into distinct views. Typical relations include Causality, Dependency, Client-Server, and Input-Output. <br />
There are a variety of ways to structure the enterprise based upon stakeholder needs, mission or charter, technologies or capabilities already in place. Among these are structuring principles including: <br />
* '''''Modularity''''' (separate and group capabilities into modules by commonalities); <br />
* '''''Network''''' (modules are linked together); <br />
* '''''Encapsulation''''' (separating architecture modules use from how they are implemented); <br />
* '''''Layer Hierarchy''''' (separation through gradual refinement); <br />
* ''''' Regularity''''' (uniformity of interactions, of structure within layer, within network). <br />
* ''''' Similarity/Difference''''' (recognizing the limits of Regularity)<br />
A simple pattern for architecture has been defined (Hofmeister ''et al. '' 2007). Its elements are Analysis, Synthesis and Evaluation. See Figure 1 below. <br />
''Architecture Analysis'' formulates architecturally-significant requirements (ASRs)—those requirements which influence an enterprise’s architecture. Architecture analysis is based on identified concerns and other information based on understanding the enterprise’s environment, known requirements, stakeholder needs and any constraints. ASRs reflect the “design problems” that the architecture must solve. In many cases, negotiations take place to modify incoming needs, requirements and expectations to make solutions possible. The result of this activity takes the form of ASRs, including architecture principles and initial enterprise-wide decisions.<br />
''Architecture Synthesis'' develops candidate solutions in response to the concerns and ASRs. During Synthesis the architect works out the details of solutions to the identified design problems, tradeoff and interactions between them which are likely to generate further design problems. Synthesis elaborates the ASRs, principles and initial decisions into more detailed solution elements. The principle of ''''' EQUIFINALITY''''' reminds us that for many stable situations (i.e., states of the enterprise), there are many ways to reach those states.<br />
''Architecture Evaluation'' validates whether chosen solutions satisfy ASRs or whether rework is needed (ISO/IEC/IEEE 42030 2019).<br />
Applying the principles discussed above is pervasive in enacting the Analysis–Synthesis–Evaluation pattern iteratively. <br />
<br />
[[File:EIT Figure 1 - Higher Resolution.png|centre|thumb|1000px|'''Figure 1. A pattern for Architecture.''']]<br />
<br />
While there are many commonalities among EIT, systems and software architectures, Figure 2 addresses the relationships ''between'' them. Viewing an enterprise as a system, the EIT architecture governs the fundamental IT decisions of the enterprise. That enterprise might be extended to “outsiders” such as vendors, suppliers and perhaps customers. Depending upon the enterprise, the ''governs'' relationship may entail very strict rules or loose guidance. <br />
Within the enterprise, the ecosystem of systems, applications and data may be viewed as a system of systems. The EIT Architecture constrains the architectures governing individual systems, applications and data stores within the enterprise, so that these are able to interoperate and otherwise “play nicely” together.<br />
<br />
[[File:EIT Figure 2.png|centre|thumb|1000px|'''Figure 2. Relating Enterprise IT, Systems and Software Architecture.''']] <br />
<br />
===Strategy and Governance===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance] for additional information. ''<br />
<blockquote><br />
[http://eitbokwiki.org/Glossary#eit Enterprise information technology] (EIT) governance is the established process of defining the strategy for the EIT organization and overseeing its execution to achieve enterprise goals. Strategic planning translates the larger enterprise’s goals into EIT goals and defines what EIT must do to achieve those goals. This effort then communicates this hierarchy of goals: EIT goals as well as how they support the enterprise’s goals. EIT governance drives needed changes to achieve those goals, while maintaining agreed levels of operation. Taking into account various perspectives (such as financial, historical, environmental, and future projections), a strategic plan is a roadmap for action and change, both vertically and horizontally, across the EIT organization. The EIT organization’s strategic plans are based on the enterprise’s strategic plans, focusing on EIT’s role in them; EIT governance provides a monitoring and control framework to achieve strategic goals and objectives. Thus, EIT governance is essential for achieving the EIT strategy and goals..<br />
-[http://eitbokwiki.org/Strategy_and_Governance EITBOK wiki]<br />
</blockquote><br />
<br />
The principle of ''''' PARSIMONY''''' applies here, too (see [[Principles of Systems Thinking]]). These principles will be designated in this article with '''''bold italics'''''. For example, the simplest possible measurement and reporting systems are most likely to be used and not corrupted. Similarly, the EIT organizational structure should be straightforward and easy to traverse so that staff can communicate and problem-solve in teams.<br />
In governing the EIT organization to meet its dual goals of satisfying its customers and meeting its budget and schedule commitments, EIT management encounters the difficulty of managing in the face of '''''dualism''''', “ensuring a constant dynamic balance often through a cyclic dominance of one element and then the other”. The most obvious instance of handling ''''' dualism''''' in EIT is the trade-off between budget, project prioritization and features within projects.<br />
===Change===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Change_Initiatives Change Initiatives] for more information. ''<br />
There are two levels of change management discussed in the EITBOK: organizational change management and changes to the IT organization’s assets, whether they be software, hardware, or telecommunications systems.<br />
In the larger sense, the introduction of new systems and services often also requires changes in people’s jobs and in the processes used to accomplish those jobs. Such efforts are intended to increase business value. Such changes require change initiatives because they involve guiding a mixture of stakeholders through the change process. This is one aspect of [http://eitbokwiki.org/Change_Initiatives change management].<br />
Change also occurs when existing systems or services must be updated to meet new needs. Depending on the scope of the proposed changes, a change initiative may be required in this situation, too. At any rate, a change request process must be initiated and tracked to disposition (deferral, rejection, or implementation). Changes also come about as a result of defect reports. In such cases, the defect report must be tracked throughout the report’s life cycle, to disposition (deferral, rejection, or implementation).<br />
These latter types of change management are discussed in detail in the EITBOK’s section on [http://eitbokwiki.org/Operations_and_Support Operations and Support].<br />
===Interoperability of Component Systems===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Interoperability interoperability] for more information. ''<br />
As explained in the [http://eitbokwiki.org/Interoperability#One EITBOK], ''interoperability'' means “the ability of systems (including organizations) to exchange and use exchanged information without knowledge of the characteristics or inner workings of the collaborating systems (or organizations).” This definition is based on an ISO definition: “degree to which two or more systems, products, or components can exchange information and use the information that has been exchanged.” (ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models, 4.2.3.2. ) Note that this definition includes hardware components as well as software systems and the organizations in which they are used.<br />
Because technology changes so rapidly, and organizations themselves are frequently changing, achieving and maintaining interoperability is crucial. It is one of the main reasons that providing IT services is difficult and how it differs from engineering and delivering finished products, whether off-the-shelf products or bespoke systems.<br />
===Security of Systems and Data===<br />
<blockquote><br />
There are only two types of companies: those that have been hacked, and those that will be.<br />
-FBI Director Robert Mueller, October 2012<br />
</blockquote><br />
<br />
<blockquote><br />
There are two kinds of big companies in the United States. There are those who've been hacked by the Chinese and those who don't know that they've been hacked by the Chinese<br />
-FBI Director James Comey, October 2014<br />
</blockquote><br />
''See the EITBOK’s section on [http://eitbokwiki.org/Security security] for additional information. ''<br />
While there are many definitions for security, most include the three dimensions of confidentiality, integrity, and availability (sometimes referred to as the [http://eitbokwiki.org/Glossary#ciatriad CIA triad]). As such, the primary goal of EIT security is to preserve the confidentiality, integrity, and availability of information and information systems. <br />
The principles behind an organization’s [http://eitbokwiki.org/Glossary#isms information security management system] (ISMS) should be to design, implement, and maintain a coherent set of policies, processes, and systems that keep the risks associated with its information assets at a tolerable level, and yet, manage the cost and inconvenience of said risk management. As such, the goals of EIT security are to:<br />
* Always understand the current risk tolerance of the enterprise with respect to information and device security.<br />
* Understand the security threats and potential damages to information, devices, and individuals.<br />
* Create and follow policies and procedures that keep cyberattack risk and damages at or below a tolerable level.<br />
* Effectively and efficiently detect and deal with<br />
[http://eitbokwiki.org/Security#One cyberattack incidents].<br />
Ensuring security in EIT has been made even more pressing and more difficult by the proliferation of mobile devices in enterprises and their ever-increasing use to conduct business. Increasingly, personal devices (Bring Your Own Device – BYOD) are used, accessing both corporate networks and public networks. The cost of [https://www.checkpoint.com/downloads/products/check-point-mobile-security-survey-report2013.pdf mobile security incidents] very easily can outweigh the cost of the mobile device itself. <br />
==Quality of Systems and Services==<br />
The Enterprise ''Information'' Technology organization has, since its origins, had as its primary responsibility the timely provision of information to the larger organization. The information is expected to be not only timely, but also accurate and relevant. While the EIT organization itself may not be responsible for creating the data, it is responsible for the physical and logical validity and [https://simplicable.com/new/data-integrity-vs-data-quality integrity of the data] that is used to construct information. It is for this reason that defining and using appropriate processes is essential to ensure high-quality operation, including the development or acquisition, implementation and integration of new or changed capabilities.<br />
The EITBoK details the quality concepts of<br />
* How to approach measuring [http://eitbokwiki.org/Quality#Measuring_Quality Quality]<br />
* The importance of Quality in [http://eitbokwiki.org/Quality#Requirements_Management Requirements Management]<br />
* Understanding an organization’s [http://eitbokwiki.org/Quality#Quality_Capability Quality Capability]<br />
* The differences between [http://eitbokwiki.org/Quality#QMS_and_QC_vs._QA QMS, QC and QA]<br />
* Cost of Quality in [http://eitbokwiki.org/Quality#Technical_Debt_and_the_Cost_of_Rework Technical Debt and the Cost of Rework]<br />
==Disaster Preparedness==<br />
<br />
As explained in the [http://eitbokwiki.org/Disaster_Preparedness EITBOK], disaster preparedness and [http://eitbokwiki.org/Glossary#dr disaster recovery] (DR) support business-continuity planning and include planning for EIT resiliency, as well as recovery from adversity, so that critical business services affected are restored to a satisfactory working state within an [http://eitbokwiki.org/Glossary#acceptable acceptable] timeframe after an event.<br />
The EITBoK devotes a chapter to how the EIT organization and its parent must plan in advance for how it will provide sufficient organizational resilience to recover from disasters and return to normal operation as rapidly as possible.<br />
It provides the following examples of disasters and service interruptions that could occur and should be considered in prevention and recovery planning:<br />
These are examples of disasters:<br />
* Natural disaster affecting datacenters or EIT service operations (flood, fire, earthquake, wind)<br />
* Security breach resulting in a disaster (destruction of data, admin password changes, virus/malware installation, sabotage)<br />
* Usage error (accidental deletion, unplug/turn off system resulting in corruption)<br />
* Utility failure affecting datacenters (loss of power even after UPS)<br />
* Vendor failure (cloud provider security failure, oil spill)<br />
* Staffing issue (employment dispute/walkout, epidemic)<br />
These are examples of unpreparedness:<br />
* Requiring use of computers or printers when power is out<br />
* Requiring use of Internet when power or connectivity is out<br />
* Single point of knowledge/control for administration access<br />
* Lack of offsite backup storage<br />
* Lack of working restoration from backups<br />
* Lack of failover datacenters in separate locations<br />
* Undocumented or out-of-date documentation for system interfaces<br />
*Requiring use of phones that are out of power<br />
* Lack of designation of leaders in restoration efforts (who is in charge of restoring service and they know they are in charge)<br />
* In general, no cohesive, comprehensive EIT service restoration plan<br />
==Operations and Support of Delivered Systems and Services==<br />
[http://eitbokwiki.org/Operations_and_Support Operations and support activities] focus on maintaining an operation normal state in EIT environments, meaning that systems and processes execute according to expectations, with no surprises to users. This desired normal state requires the careful management of EIT assets and services via Operations, as well as of users via Support.<br />
Normal states can be disrupted either by the expected and planned transition of an asset, or by an unexpected event, be it as large as a disaster or by the discovery of a system defect. In the former case, the Disaster Recovery Plan is executed; in the latter, incident management kicks in when a system halts, or problem management is exercised when an operational system is not functioning as expected. The processes needed to ensure effective application of these complex functions is detailed in the [http://eitbokwiki.org/Operations_and_Support#Guiding_Principles Operations and Support Knowledge Area] within the EITBOK. <br />
ISO/IEC/IEEE 20000 may be used by any organization to develop and manage EIT operations, along with the current version of [https://www.servicenow.com ITIL].<br />
ITIL for many is the tool of choice for the operations and infrastructure side of IT, particularly for IT services. <br />
==Ethics==<br />
See the EITBOK’s section on [http://eitbokwiki.org/Ethics ethics] for additional information.<br />
Both the IEEE and ACM require their members to adhere to Codes of Ethics. See the [https://www.ieee.org/about/corporate/governance/p7-8.html IEEE Code of Ethics] and [https://www.acm.org/code-of-ethics ACM Code of Ethics and Professional Conduct]. Both of these can be downloaded freely. In addition, the IEEE Computer Society and the ACM worked together on the [https://dl.acm.org/action/downloadSupplement?doi=10.1145%2F265684.265699&file=acm-se-code-of-ethics.html Software Engineering Code of Ethics] (also available [https://dl.acm.org/doi/10.1145/265684.265699 here]).<br />
The organization should create an easily accessible Code of Ethics:<br />
* Ethical assertions should be documented and socialized in EIT in the form of a Code of Ethics, tied to the overall business code of ethics, and signed off by all staff so that violations can be cause for reprimand or dismissal.<br />
* Vendors should be held to similar ethical standards.<br />
* Lists of employees who have signed off on the Code of Ethics are maintained by EIT governance.<br />
The EITBOK has identified EIT ethical topics that include:<br />
* Those actions and decisions that may be illegal<br />
* Consideration of the social impact of the work at hand—if it will cause harm<br />
* Alignment of business and EIT strategies and policies to an ethical standard<br />
* Incorporation of the ideals of professionalism<br />
* Adherence to applicable regulatory intent<br />
* Protection for whistle blowers<br />
Areas to specifically highlight:<br />
* Activities that interfere with or corrupt the proper function of computers, applications and systems<br />
* Activities that interfere with digital privacy or intellectual rights of others<br />
* Respect for confidentiality, privacy, permissions, and access rights<br />
* Inappropriate bias (skewing) of analysis and reporting<br />
* Inaction in the face of likely ethics violations<br />
==EIT Roles==<br />
Several roles play a part in accomplishing the EIT organization’s mission. Just as a systems engineer can play several roles in a given project, so might several people in an EIT project combine to fulfill the systems engineering function. <br />
The function of EIT systems engineering is to orchestrate systems development, delivery and operation such that the larger organization achieves favorable outcomes in complex environments. Unlike systems projects that are built for known problems, EIT systems may change in unpredictable ways. A primary concern focuses on how quickly systems adapt to change. This entails a type of resiliency based on skills in establishing options and alternative solutions as well as strategies tailored to the volatility of changing needs and available technologies. It also requires expertise in assuring that systems quality is assured from the start.<br />
Different countries, geographic areas and organizations do not always use the same terminology to reference the functions that the roles contributing to systems engineering perform. The following section will provide information about some major international models for defining EIT skills and capabilities. Generally, though, the necessary roles across the product life cycle include these:<br />
* Business Sponsor/Champion<br />
* Enterprise Architect<br />
* Systems Engineer<br />
* Financial Manager<br />
* Application Architect<br />
* Business Analyst and/or Process Analyst<br />
* Data Analyst and/or Data Architect<br />
* Software Engineer and/or Programmer<br />
* Quality Assurance & Testing<br />
* Network Engineer<br />
* Telecoms Engineer<br />
* Integration Expert <br />
* Transition to Operations Manager<br />
* Release Manager<br />
* Availability Manager<br />
* Capacity Manager<br />
* Change Manager<br />
* Configuration Manager<br />
* EIT Operations Manager<br />
* Incident Management<br />
* Problem Manager<br />
* Service Level Manager<br />
* Database Administrator<br />
* Network Manager<br />
* Product Manager<br />
System engineering activities orchestrate the work of these roles so that they function together, rather than in silos or at cross purposes.<br />
==Examples of Systems Engineering in EIT==<br />
Systems Engineering provides a holistic discipline for integrating and managing the contributions of all roles needed to establish and provide EIT products and services. It ensures that a single perspective does not dominate outcomes; instead, it seeks balance among the many disciplines represented above in creating a consistent product or service that meets the interests and needs of enterprise users (and, perhaps, partners). It boils down to common sense, technical sense, knowing when to ask the right questions, and getting the data to support the answers to those questions. System Engineering achieves this via Systems Engineers. In many instances, though, the SE function is accomplished through Project Management approaches using Integrated Product Teams that include technical experts. Thus, although not specifically calling out a Systems Engineering function, the use of IPTs involved the use of SE practices.<br />
A doctoral dissertation from Purdue University performed a survey and causal analysis of project failures and of accidents(Aloisio, 2018). The results were similar to those found in reviews of IBM consulting projects in the 1990s . The following are examples of Systems Engineering interventions that prevented project failures. Almost all point to the lack of the System Engineering balancing act needed for product delivery.<br />
* A widely used document processing product was undergoing a major upgrade. The new VP of Engineering wanted a project review before committing to a schedule. The review showed that the proposed schedule only considered the development effort and did not give sufficient weight to the voices of the testing and documentation organizations, while the needs of the tech support group had been completely overlooked. By establishing an integrated product management team that included technical expertise, as well as expertise in work breakdown and estimating, a realistic effort was defined and the resulting 9-month schedule was met within 3 weeks.<br />
* A Silicon Valley start-up was depending entirely on an offshore development effort to produce its first product. All senior management was in the U.S. The VP of engineering made monthly visits to the development team. The CEO began to feel uneasy about the team’s ability to deliver on schedule sensing that a lot of finger pointing within the development team itself signaled problems. There was no SE or IPT guiding the project. The VP of Engineering seemed unable to sort things out. A project review showed that the probable delivery date was at least 6 months beyond what the CEO was being told. The project was shut down.<br />
* A major player in Human Resource Management had made commitments to deliver a new product. The project involved more than 100 people across the U.S. The delivery date kept slipping. Project roll-out would involve both installation of software and hardware at client sites, as well as installation and staff training at the large, centrally located Client Services organization. Executive Management needed to decide whether to reorganize this very expensive effort or cancel it. Again, the successful solution depended on establishing an effective cross-functional team (IPT) that necessarily included representatives from the technical teams. The IPT was supported by a newly established Project Management Office (PMO). The PMO integrated the geographically disparate efforts by establishing communication channels, as well as common estimating and scheduling practices. The PMO also instituted monthly critical metrics reports to show the IPT bottlenecks and inefficiencies across the project, from development efforts to Client Services set-up to Payroll technical support.<br />
There are far more examples of the lack of systems engineering practices in EIT projects than in their successful use (unfortunately, this seems also to be true in lots of software projects outside of EIT). Systems Engineering provides a holistic discipline for integrating and managing the contributions of all of the roles needed to provide EIT products and services. It ensures that a single perspective does not dominate outcomes.<br />
==Key External Models of EIT Organizational Capability and Maturity==<br />
Because EIT is critical to businesses globally, considerable effort has gone into establishing universal frameworks for EIT skills, along with definitions of levels of capability of each skill. In addition, at least 2 models have been developed for evaluating the organizational performance of EIT. The effectiveness of systems engineering is key to the effectiveness of the EIT organization.<br />
===IT-CMF: IT-Capability Maturity Framework=== <br />
The IT-CMF had its origin in a quality improvement effort at Intel Labs Europe in Ireland. Its intent, as described at the <br />
[https://cio-wiki.org/wiki/IT_Capability_Maturity_Framework_(IT-CMF) CIO Index website] was to quantify and demonstrate the true value impact of IT. IT-CMF is used to measure, develop, and monitor an organization’s EIT capability maturity. It consists of 35 EIT management capabilities organized into four macro capabilities: managing EIT like a business; managing the EIT budget; managing the EIT capability; and managing EIT for business value. Its 35 critical capabilities (CCs) are [http://eitbokwiki.org/Enterprise_IT_Maturity_Assessment described] as “A defined EIT management domain that helps mobilize and deploy EIT-based resources to effect a desired end, often in combination with other resources and capabilities”. <br />
===CMMI: Capability Maturity Model Integration (US)===<br />
The CMMI had its origin in 1987 in a model requested by the U.S. Department of Defense for determining the capability maturity of contractor software development organizations. This became the Capability Maturity Model (CMM). Since then, it has been expanded into a set of Capability Maturity Models, all based on five levels of demonstrably increasing maturity as measured by organization performance. That set was then integrated and became the CMMI. The CMMI set addresses [https://cmmiinstitute.com/dev Development], [https://cmmiinstitute.com/svc Services], [https://cmmiinstitute.com/sm Supplier Management], [https://cmmiinstitute.com/pm People Management], and [https://cmmiinstitute.com/dm Data Management].<br />
===SFIA: Skills Framework for the information Age (Europe, Canada and US)===<br />
The SFIA Framework has been downloaded and used by organizations and individuals in nearly 180 countries. It can be downloaded for free at [https://www.sfia-online.org]. It identifies 97 professional skills across EIT and supporting areas with seven levels of responsibility, which provide generic levels of responsibility, taking into account reflect experience and competency. These describe the behaviors, values, knowledge, and characteristics that an individual should have in order to be considered competent at a particular level.<br />
===E-CF: European Competency Framework (EU)===<br />
The ECF was the first sector-specific implementation of the European Qualifications Framework (EQF). The European Norm (EN) 16234-1 European e-Competence Framework (e-CF) provides a reference of 41 competences as applied at the Information and Communication Technology (ICT) workplace, using a common European reference for competences, skills, knowledge and proficiency levels. The E-CF Explorer web tool is available [https://ecfexplorer.itprofessionalism.org/ online].<br />
===I Competency Dictionary: EIT skills as Defined by METI/ IPA (Japan)===<br />
The Japanese government’s Information-Technology Promotion Agency (IPA), established by the Ministry of Economy, Trade and Industry (METI) developed the ”I Competency Dictionary” (iCD) to support the IT Engineers Examination. It underlies the METI/IPA Skills Standards for IT Professionals, abbreviated as ITSS, established in 2002. ITSS organizes skills within the information services industry into 11 job categories and 35 specialty fields. In each field, there are seven levels of competence based on individual experience and ability to perform. One appealing feature of ITSS is that this standard allows engineers to draw roadmaps for their own futures and career advancement (Career Path). Approximately 90% of large enterprises and over 60% of SMEs in Japan have introduced or are considering using ITSS. Information in English is available at https://www.ipa.go.jp/english/humandev/forth.html.<br />
===ITIL: Information Technology Infrastructure Library===<br />
According to ITLIlibrary.org, the ITIL Open Guide website, “The Information Technology Infrastructure Library (ITIL) defines the organisational structure and skill requirements of an information technology organisation and a set of standard operational management procedures and practices to allow the organisation to manage an IT operation and associated infrastructure. … The [https://www.itlibrary.org/ “library”] itself continues to evolve. This comprises five distinct areas: <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Strategy ITIL Service Strategy]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Design ITIL Service Design]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Transition ITIL Service Transition]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Operation ITIL Service Operation]; and <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Continual_Service_Improvement ITIL Continual Service Improvement].”<br />
It originally grew out of a British government sponsored effort to regularize IT Service Management (ITSM). <br />
==References==<br />
===Works Cited===<br />
Fong, E.N. and A.H. Goldfine. 1989. ''Information Management Directions: The Integration Challenge. '' National Institute of Standards and Technology (NIST) Special Publication 500-167, September 1989. https://csrc.nist.rip/library/NIST%20SP%20500-167.pdf <br />
<br />
Hammer, M., T.H. Davenport and J. Champy. 1986. ''Dispersion and Interconnection: Approaches to Distributed Systems Architecture'', Cambridge, MA: CSC Index Inc. and Hammer and Company, Inc. (June 1986). Available as: https://www.globalaea.org/general/custom.asp?page=Resources <br />
<br />
Hilliard, R. 2015. “Lessons from the fundamental unity of architecting”. ''Software Engineering in the Systems Context'', editors: Ivar Jacobson and Harold 'Bud' Lawson.<br />
<br />
Hofmeister, C. et al. 2007. “A general model of software architecture design derived from five industrial approaches”. ''The Journal of Systems and Software'' 80(1). <br />
<br />
ISO/IEC 25010:2011 ''Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models'', 4.2.3.2.<br />
<br />
ISO/IEC/IEEE 42010 Users Group. ''Survey of Architecture Frameworks'' Available as: http://www.iso-architecture.org/42010/afs/<br />
<br />
ISO/IEC/IEEE. 2011. ISO/IEC/IEEE 42010:2011, ''Systems and software engineering — Architecture description. ''<br />
<br />
PMI. 2013. ''Software Extension to PMBOK® Guide – Fifth Edition. '' Newtown Square, PA, USA: Project Management Institute (PMI). Available as: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/software-extension-5th-edition.<br />
<br />
Rivera, R. 2013. “The PRISM Architecture Framework – Was it the Very First Enterprise Architecture Framework?” ''Journal of Enterprise Architecture'', November 2013<br />
<br />
Zachman, J. 1987. “A Framework for Information Systems Architecture”. ''IBM Systems Journal'', pp454-470, 1987 <br />
<br />
===Primary References===<br />
IEEE Computer Society. ''Enterprise IT Body of Knowledge''. Available: http://eitbokwiki.org<br />
<br />
=-=Additional References===<br />
IT Capability Maturity Framework (IT-CMF): The Body of Knowledge Guide. 2015. Editors. Martin Curley, Jim Kenneally, Marian Carcary. Van Haren Publishing.<br />
<br />
Lessons from Systems Engineering Failures: Determining Why Systems Fail, The State of Systems Engineering Education, and Building an Evidence-Based Network to Help Systems Engineers Identify and Fix Problems on Complex Projects, Diane Constance Aloisio, December 2018.<br />
<br />
===International Standards Guiding EIT===<br />
ANSI/AIAA. 2012. ''ANSI/AIAA Guide to the Preparation of Operational Concept Documents. '' ANSI/AIAA G-043A-2012e.<br />
<br />
IEEE 2012 Std 828™-2012, ''IEEE Standard for Configuration Management in Systems and Software Engineering. ''<br />
<br />
ISO 10004:2012, Quality management—Customer satisfaction—Guidelines for monitoring and measuring<br />
<br />
ISO 10007:2003, Quality management systems—Guidelines for configuration management<br />
<br />
ISO 18238:2015, Space systems—Closed loop problem solving management<br />
<br />
ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models<br />
<br />
ISO/IEC 16350:2015, Information technology—Systems and software engineering—Application management<br />
<br />
ISO/IEC 19770-1:2012, Information technology—Software asset management—Part 1: Processes and tiered assessment of conformance<br />
<br />
ISO/IEC 20000-1:2011, (IEEE Std 20000-1:2013) Information technology—Service management—Part 1: Service management system requirements<br />
<br />
ISO/IEC 20000–2:2012, Information technology—Service management—Part 2: Guidance on the application of service management systems<br />
<br />
ISO/IEC TR 20000–10:2015, Information technology—Service management—Part 10: Concepts and terminology<br />
<br />
ISO/IEC TR 20000–11:2015, Information technology—Service management—Part 11: Guidance on the relationship between ISO/IEC 20000-1:2011 and related frameworks: ITIL®<br />
<br />
ISO/IEC TR 20000-12—Information technology—IT Service management—Part 12: Guidance on the relationship between ISO/IEC 20000-1:2011 and service management frameworks: CMMI-SVC®<br />
<br />
ISO/IEC/IEEE 14764-2006, Software Engineering—Software Lifecycle Processes—Maintenance<br />
<br />
ISO/IEC 15939:2007, Systems and software engineering—Measurement process<br />
<br />
ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description <br />
<br />
<br />
----<br />
<center>[[ Systems Engineering and Economics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Quality Attributes|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Enterprise_IT&diff=66943
Systems Engineering and Enterprise IT
2023-05-07T04:02:44Z
<p>Mhaas: </p>
<hr />
<div>----<br />
'''''Lead Authors:''''' Chuck Walrad and Richard Hilliard<br />
----<br />
This article forms part of the [[Related Disciplines]] knowledge area (KA). It discusses enterprise IT, building upon the concepts and practices of Systems Engineering presented elsewhere in the SEBOK. Systems Engineering is integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of ''engineered technical systems''. <br />
<br />
== Enterprise IT Introduction==<br />
Although it had its origin in the need to improve success rates in U.S. Government outsourcing of technical systems, Systems Engineering is also integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of [https://www.incose.org/about-systems-engineering/system-and-se-definition/systems-engineering-definition#ENGINEERED_SYSTEM engineered technical systems].<br />
Examples of EIT systems include enterprise resource planning, supply chain management and customer relationship management systems, accounting, finance, inventory and order management, marketing, planning, purchasing, and sales.<br />
In the late 1980s and throughout the 1990s, EIT organizations became increasingly aware that the success rates of IT projects were very low, and that their enterprise customers were increasingly unhappy with their EIT investments. The Standish Group sought to understand what was going on. Their findings were presented in the [https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf Chaos Report] (1994):<br />
The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable but could easily be in the trillions of dollars.<br />
As a result, commercial IT organizations, through the auspicious parallel emergence of the Total Quality Management movement and the increasingly widespread development of application development methodologies (ADM) by IT management consulting firms, recognized the need for the principles of Systems Engineering and cross-functional teams (Integrated Product Teams [https://www.sebokwiki.org/wiki/Integrated_Product_Team_(IPT)_(glossary)]. It should be noted that there is considerable overlap today between what constitutes Systems Engineering and what constitutes [[Portfolio Management|Relationships between Systems Engineering and Project Management]] (see [https://www.pmi.org/learning/library/bridging-gap-program-management-systems-engineering-6213 PMI]). This article does not attempt to resolve this issue. Note that the “[[Related Business Activities|following business management activities]] can be ''supported'' by enterprise systems engineering (ESE) activities” [emphasis added]: <br />
* mission and strategic planning,<br />
* business processes and information management,<br />
* performance management,<br />
* portfolio management,<br />
* resource allocation and budgeting, and<br />
* program and project management.<br />
Note that these same areas have been designated as being supported by Project Management Offices. However, since a key difference between project management and systems engineering has been identified as the requirement that the latter includes technical expertise in the product/system of concern, focus should be on systems engineering and integrated product teams (IPTs). <br />
With IPTs, each product is shepherded from concept through delivery and support to retirement by a cross-functional team that includes representatives from each area of responsibility, such as customer requirements development, design and development, test, configuration management, release engineering, delivery, and support.<br />
As enterprises have come to depend more and more on technology to perform effectively, Enterprise IT organizations have matured, often due to the influence of IT consulting firms that make it their business to keep abreast of best practices.<br />
<br />
== EIT Concepts ==<br />
This knowledge area (KA) discusses enterprise IT, building upon the concepts elucidated in the IEEE/ACM ''[http://eitbokwiki.org EITBOK Guide to the Enterprise Information Technology Body of Knowledge]'' and general concepts of Systems Engineering elsewhere in SEBOK. <br />
An enterprise may be viewed from various perspectives: such as a system or a [[Enterprise Systems Engineering|system of systems (SoS)]]:<br />
* system-like enterprise: enterprises, like other systems, may have a tight coupling, single-executive function; <br />
* system of systems-like enterprise: may be a loosely coupled group of organizations with blurred boundaries and (yet) with (some) shared outcomes.<br />
The choice of perspective may vary with many factors: the enterprise itself, the mission or purpose, or the particular engineering task at hand. We can view an enterprise as a system with inputs and outputs in relation to the outside world, or a system of systems interacting through their individual inputs and outputs. <br />
An enterprise usually involves one (or more) organization(s) but need not be identified with the organization. As the scope of human and organizational participants of the enterprise widen, there may be no single point of control. For example, an ''extended enterprise'' could include a company, its suppliers and customers.<br />
Whatever perspective (system-like, SoS-like, other) is taken there are [[Enterprise Systems Engineering Background|key ingredients]] of any enterprise: capabilities, individual (competencies) and the organizational design. [[Enterprise Capability Management|Capabilities]] can be further categorized: “There are three different kinds of capability: organizational capability, system capability, and operational capability.” These capabilities determine what the enterprise is able to produce which may be external offerings or internal mechanisms. Operational capabilities create services and/or products which in turn produce value as determined by stakeholders. The capabilities of an enterprise are realized through [[Enterprise Systems Engineering Background|various enterprise elements]], including: “hardware, software, personnel, facilities, data, materials, techniques, and even services”. which include “soft” items, like people, processes, principles, policies, practices, organizations, doctrine, theories, and beliefs.<br />
EIT capabilities exist through lifecycles spanning from creation through eventual replacement and disposal. ''Life cycle models'' are schemes to aid in the understanding, design, planning and management of the capability of interest. <br />
“A life cycle for a system generally consists of a series of stages regulated by a set of management decisions which confirm that the system is mature enough to leave one stage and enter another.” Basic life cycle terms and concepts are discussed in [[System Lifecycle Approaches]]. Some typical life cycles are discussed in [[Systems Lifecycle Models]].<br />
A life cycle-based approach can be deployed across the several levels and used to manage evolution. These levels are:<br />
* the enterprise itself,<br />
* the processes and organizations constituting the enterprise,<br />
* the systems enabling the capabilities, services or products provided. <br />
It is important to distinguish between ''product'' and ''project'' lifecycle models. A product’s life cycle extends from its initial concept approval, through development and distribution, to its retirement. This is the cycle that is managed within an Enterprise IT organization, since EIT must manage the hardware or software product from its introduction, in the case of acquired capabilities, or from its concept approval and development, in the case of capabilities it builds, through its deployment, maintenance and eventual retirement (withdrawal). Each of these stages is usually managed as a project or a series of projects.<br />
However, most discussions of life cycles within software and systems discussions focus on ''project'' life cycles. See, for example, the ''Software Extension to PMBOK Guide'' (PMI 2013).<br />
==System of Systems Context in EIT==<br />
“Enterprise IT” (EIT) is used both to refer to the technology organization/business unit within the enterprise and to the enterprise’s information technology systems. In this article, we use EIT to refer to the technology systems. When referring to the organization, we use the phrase “Enterprise IT organization” or EIT organization. <br />
Enterprise IT organizations are responsible for complex socio-technical systems. Socio-technical systems in a business context (thus, EIT) contain technical elements (software, hardware, networks, storage, databases, etc.) but they also contain essential human components and necessary business processes. As covered in [[Introduction to Systems Engineering Fundamentals]], they exist in an engineered System Context that is a set of system component interrelationships within a real-world environment:<br />
This includes where problems come from and how they are defined, how we identify and select candidate solutions, how to balance technology and human elements in the wider solution context, how to manage the complex organizational systems needed to develop new solutions, and how developed solutions are used, sustained and disposed of. … Systems Engineering should consider the full Engineered System Context so that the necessary understanding can be reached and the right systems engineering decisions can be made. <br />
Socio-technical systems also have the following key characteristics: ''Openness'' in that they strongly interact with their environments, and ''unfinished'' in that they evolve over time.<br />
A complex of EIT systems is essential to the successful functioning of the humans in the enterprise. They rely on EIT’s technology for communication, for paying employees, for people management, for business measurement, and often for managing supply chains. Thus, “EIT needs to be viewed as a strategic partner to all the other functions and business units within an enterprise. This means that the results produced by EIT along with its effectiveness and efficiency are all critically important to the success of the enterprise.” [http://eitbokwiki.org/What_is_the_Enterprise_Perspective%3F]<br />
To accomplish this mission, the EIT organization builds and acquires new systems or system components, integrates them into the mega System of Systems, and maintains the integrity and interoperability of the individual components, but also the integrity of the entire complex of systems. In addition, security and performance levels must be achieved, benchmarked and maintained or improved.<br />
==Major concerns of the EIT Organization==<br />
The [http://eitbokwiki.org ''Enterprise IT Body of Knowledge''] provides a good deal of information about these major concerns, which we will not replicate here. Rather, links to the relevant areas are provided. The EITBOK demonstrates how, in providing technology systems and services to the enterprise, the EIT organization must skillfully manage such concerns as the following.<br />
<br />
===Enterprise Architecture===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Enterprise_Architecture Enterprise Architecture] for additional information. ''<br />
[http://eitbokwiki.org/Glossary#ea ''Enterprise architecture''] (EA) is the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. EA applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their organization's strategies. Enterprise architecture builds upon many of the concepts and practices of [[System Architecture Definition|systems architecture]] and also software architecture [https://www.sebokwiki.org/wiki/System_Architecture_Definition].<br />
This section will discuss Enterprise Architecture from the perspective of key [[Principles of Systems Thinking]], designated in this article with '''''bold italics'''''. There are many commonalities in architecture whether one is architecture systems, software or the enterprise [Unity]. In this article we highlight both commonalities and differences between Enterprise Architecture and Systems Architecture. <br />
Architecture takes place at the juncture of design problems and their solutions. Design problems rarely arrive fully formulated or “hatched” for the architect; much of the architecture effort is to analyze or formulate the problems to be solved. Often this involves negotiation both within the enterprise and with outside stakeholders. Possible solutions are limited by resources and schedule and therefore often must also be negotiated.<br />
A dominant principle of Enterprise Architecture is '''''separation of concerns''''' (SoC). This is due to the complexity of enterprises, with many forces acting upon them; the many technologies and disciplines involved in their creation and day-to-day operations; and due to the diversity of stakeholders involved in the enterprise (see [[EIT Roles]]). <br />
An application of SoC is the '''''boundary''''' principle which is crucial to separate what is “inside” the enterprise from what is “outside”. While the former is often under the enterprise’s control, the latter is often beyond its control. <br />
For some systems, determining the boundary is a key decision, subject to many possibilities and consequences. This is perhaps less the case for enterprises whose bounds are determined by the extent of organizations, regulations, supply chains or other criteria. Within an established boundary, the '''''holism''''' principle applies: to treat the enterprise as a unified whole, and, in particular, with respect to the '''''interaction''''' of the enterprise with its ''environment''—including stakeholders, other enterprises and systems. From an enterprise IT perspective, an enterprise is a ''system of systems. '' SoC offers a way to focus on the constituent systems in terms of their interconnections to one another to form the enterprise.<br />
Another useful application of SoC is to apply the principle of '''''multiple views''''' to depict the architecture of the enterprise in different ways to address the diverse interests (i.e., ''concerns'') of an enterprise’s various stakeholders. Each ''architecture view'' presents a specific perspective on the enterprise. To be understandable to its audiences (those various stakeholders), each view should follow the conventions of its ''architecture viewpoint'' (ISO/IEC/IEEE 42010 2011). Just as a map should have a legend, each view should have a documented viewpoint providing a prescribed set of conventions for looking at the enterprise through the resulting view. A viewpoint definition serves as a contract between the architect and stakeholders on ''how'' a selected set of concerns are to be addressed. Each viewpoint allows the architect to consider the enterprise in terms of various kinds of elements and relations among them and to present that view to those “concerned” stakeholders. Dominating concerns in enterprise architecture include interoperability, quality of systems and services, operations, managing change, and alignment with the enterprise’s mission, market, and technology. Via the principle of '''''dualism''''', we recognize that some viewpoints are paired, such as with process/data duality. Another pervasive duality in the enterprise is of people/technology in terms of what capabilities are automated and which are performed by people.<br />
In support of enterprise architecture, there are numerous ''enterprise architecture frameworks'' each providing a pre-defined, integrated set of viewpoints to frame typical, recurring concerns (ISO/IEC/IEEE 42010 Users Group 2022). The earliest recorded framework was (Hammer et al. 1986), developed in the mid-1980s in response to growing availability of distributed computing to the enterprise (Rivera 2013). In the late 1980s, US NIST created its Enterprise Architecture Model as a guide for US federal departments to organize their IT offerings (Fong and Goldfine 1989). NIST’s 5-layer model remains influential today. Despite never using the term “enterprise,” Zachman’s information systems architecture has had a major influence on how subsequent frameworks have been organized and depicted using grids or cubes. Later frameworks have evolved in response to emerging concepts, such as the move from client-server to service-oriented applications, as in the OASIS SOA Reference Model and its associated framework. The 1990s saw a proliferation of frameworks for defense enterprises including US DODAF, UK MODAF, NATO’s NAF and led to successors such as OMG’s UAF.<br />
Yet another application of '''''separation of concerns''''' is distinguishing today’s needs versus facilitating future needs; balancing '''''stability/change''''' and highlighting the temporal planning aspect of architecture of the enterprise. In concert with applying SOC, the architect uses the principle of '''''abstraction''''' to “forget” some details of the subject and thus focus on essentials. Just as SoC is a way of taking things apart, '''''abstraction''''' is a way of unifying or putting like things together through generalization. These two principles are perhaps the most central to architecture. SoC and abstraction work together: SoC picks out subjects and abstraction helps architects to focus upon the essentials of each subject. <br />
Returning to the '''''boundary''''' and '''''holism''''' principles, the enterprise architect applies these recursively. As architecting proceeds, the internal details of the enterprise become known in terms of '''''interaction''''' among its parts and other '''''relations'''''. Again, '''''multiple views''''' are used to factor specific '''''relations'''''into distinct views. Typical relations include Causality, Dependency, Client-Server, and Input-Output. <br />
There are a variety of ways to structure the enterprise based upon stakeholder needs, mission or charter, technologies or capabilities already in place. Among these are structuring principles including: <br />
* '''''Modularity''''' (separate and group capabilities into modules by commonalities); <br />
* '''''Network''''' (modules are linked together); <br />
* '''''Encapsulation''''' (separating architecture modules use from how they are implemented); <br />
* '''''Layer Hierarchy''''' (separation through gradual refinement); <br />
* ''''' Regularity''''' (uniformity of interactions, of structure within layer, within network). <br />
* ''''' Similarity/Difference''''' (recognizing the limits of Regularity)<br />
A simple pattern for architecture has been defined (Hofmeister ''et al. '' 2007). Its elements are Analysis, Synthesis and Evaluation. See Figure 1 below. <br />
''Architecture Analysis'' formulates architecturally-significant requirements (ASRs)—those requirements which influence an enterprise’s architecture. Architecture analysis is based on identified concerns and other information based on understanding the enterprise’s environment, known requirements, stakeholder needs and any constraints. ASRs reflect the “design problems” that the architecture must solve. In many cases, negotiations take place to modify incoming needs, requirements and expectations to make solutions possible. The result of this activity takes the form of ASRs, including architecture principles and initial enterprise-wide decisions.<br />
''Architecture Synthesis'' develops candidate solutions in response to the concerns and ASRs. During Synthesis the architect works out the details of solutions to the identified design problems, tradeoff and interactions between them which are likely to generate further design problems. Synthesis elaborates the ASRs, principles and initial decisions into more detailed solution elements. The principle of ''''' EQUIFINALITY''''' reminds us that for many stable situations (i.e., states of the enterprise), there are many ways to reach those states.<br />
''Architecture Evaluation'' validates whether chosen solutions satisfy ASRs or whether rework is needed (ISO/IEC/IEEE 42030 2019).<br />
Applying the principles discussed above is pervasive in enacting the Analysis–Synthesis–Evaluation pattern iteratively. <br />
<br />
[[File:EIT Figure 1 - Higher Resolution.png|centre|thumb|1000px|'''Figure 1. A pattern for Architecture.''']]<br />
<br />
While there are many commonalities among EIT, systems and software architectures, Figure 2 addresses the relationships ''between'' them. Viewing an enterprise as a system, the EIT architecture governs the fundamental IT decisions of the enterprise. That enterprise might be extended to “outsiders” such as vendors, suppliers and perhaps customers. Depending upon the enterprise, the ''governs'' relationship may entail very strict rules or loose guidance. <br />
Within the enterprise, the ecosystem of systems, applications and data may be viewed as a system of systems. The EIT Architecture constrains the architectures governing individual systems, applications and data stores within the enterprise, so that these are able to interoperate and otherwise “play nicely” together.<br />
<br />
[[File:EIT Figure 2.png|centre|thumb|1000px|'''Figure 2. Relating Enterprise IT, Systems and Software Architecture.''']] <br />
<br />
===Strategy and Governance===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance] for additional information. ''<br />
<blockquote><br />
[http://eitbokwiki.org/Glossary#eit Enterprise information technology] (EIT) governance is the established process of defining the strategy for the EIT organization and overseeing its execution to achieve enterprise goals. Strategic planning translates the larger enterprise’s goals into EIT goals and defines what EIT must do to achieve those goals. This effort then communicates this hierarchy of goals: EIT goals as well as how they support the enterprise’s goals. EIT governance drives needed changes to achieve those goals, while maintaining agreed levels of operation. Taking into account various perspectives (such as financial, historical, environmental, and future projections), a strategic plan is a roadmap for action and change, both vertically and horizontally, across the EIT organization. The EIT organization’s strategic plans are based on the enterprise’s strategic plans, focusing on EIT’s role in them; EIT governance provides a monitoring and control framework to achieve strategic goals and objectives. Thus, EIT governance is essential for achieving the EIT strategy and goals..<br />
-[http://eitbokwiki.org/Strategy_and_Governance EITBOK wiki]<br />
</blockquote><br />
<br />
The principle of ''''' PARSIMONY''''' applies here, too (see [[Principles of Systems Thinking]]). These principles will be designated in this article with '''''bold italics'''''. For example, the simplest possible measurement and reporting systems are most likely to be used and not corrupted. Similarly, the EIT organizational structure should be straightforward and easy to traverse so that staff can communicate and problem-solve in teams.<br />
In governing the EIT organization to meet its dual goals of satisfying its customers and meeting its budget and schedule commitments, EIT management encounters the difficulty of managing in the face of '''''dualism''''', “ensuring a constant dynamic balance often through a cyclic dominance of one element and then the other”. The most obvious instance of handling ''''' dualism''''' in EIT is the trade-off between budget, project prioritization and features within projects.<br />
===Change===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Change_Initiatives Change Initiatives] for more information. ''<br />
There are two levels of change management discussed in the EITBOK: organizational change management and changes to the IT organization’s assets, whether they be software, hardware, or telecommunications systems.<br />
In the larger sense, the introduction of new systems and services often also requires changes in people’s jobs and in the processes used to accomplish those jobs. Such efforts are intended to increase business value. Such changes require change initiatives because they involve guiding a mixture of stakeholders through the change process. This is one aspect of [http://eitbokwiki.org/Change_Initiatives change management].<br />
Change also occurs when existing systems or services must be updated to meet new needs. Depending on the scope of the proposed changes, a change initiative may be required in this situation, too. At any rate, a change request process must be initiated and tracked to disposition (deferral, rejection, or implementation). Changes also come about as a result of defect reports. In such cases, the defect report must be tracked throughout the report’s life cycle, to disposition (deferral, rejection, or implementation).<br />
These latter types of change management are discussed in detail in the EITBOK’s section on [http://eitbokwiki.org/Operations_and_Support Operations and Support].<br />
===Interoperability of Component Systems===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Interoperability interoperability] for more information. ''<br />
As explained in the [http://eitbokwiki.org/Interoperability#One EITBOK], ''interoperability'' means “the ability of systems (including organizations) to exchange and use exchanged information without knowledge of the characteristics or inner workings of the collaborating systems (or organizations).” This definition is based on an ISO definition: “degree to which two or more systems, products, or components can exchange information and use the information that has been exchanged.” (ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models, 4.2.3.2. ) Note that this definition includes hardware components as well as software systems and the organizations in which they are used.<br />
Because technology changes so rapidly, and organizations themselves are frequently changing, achieving and maintaining interoperability is crucial. It is one of the main reasons that providing IT services is difficult and how it differs from engineering and delivering finished products, whether off-the-shelf products or bespoke systems.<br />
===Security of Systems and Data===<br />
<blockquote><br />
There are only two types of companies: those that have been hacked, and those that will be.<br />
-FBI Director Robert Mueller, October 2012<br />
</blockquote><br />
<br />
<blockquote><br />
There are two kinds of big companies in the United States. There are those who've been hacked by the Chinese and those who don't know that they've been hacked by the Chinese<br />
-FBI Director James Comey, October 2014<br />
</blockquote><br />
''See the EITBOK’s section on [http://eitbokwiki.org/Security security] for additional information. ''<br />
While there are many definitions for security, most include the three dimensions of confidentiality, integrity, and availability (sometimes referred to as the [http://eitbokwiki.org/Glossary#ciatriad CIA triad]). As such, the primary goal of EIT security is to preserve the confidentiality, integrity, and availability of information and information systems. <br />
The principles behind an organization’s [http://eitbokwiki.org/Glossary#isms information security management system] (ISMS) should be to design, implement, and maintain a coherent set of policies, processes, and systems that keep the risks associated with its information assets at a tolerable level, and yet, manage the cost and inconvenience of said risk management. As such, the goals of EIT security are to:<br />
* Always understand the current risk tolerance of the enterprise with respect to information and device security.<br />
* Understand the security threats and potential damages to information, devices, and individuals.<br />
* Create and follow policies and procedures that keep cyberattack risk and damages at or below a tolerable level.<br />
* Effectively and efficiently detect and deal with<br />
[http://eitbokwiki.org/Security#One cyberattack incidents].<br />
Ensuring security in EIT has been made even more pressing and more difficult by the proliferation of mobile devices in enterprises and their ever-increasing use to conduct business. Increasingly, personal devices (Bring Your Own Device – BYOD) are used, accessing both corporate networks and public networks. The cost of [https://www.checkpoint.com/downloads/products/check-point-mobile-security-survey-report2013.pdf mobile security incidents] very easily can outweigh the cost of the mobile device itself. <br />
==Quality of Systems and Services==<br />
The Enterprise ''Information'' Technology organization has, since its origins, had as its primary responsibility the timely provision of information to the larger organization. The information is expected to be not only timely, but also accurate and relevant. While the EIT organization itself may not be responsible for creating the data, it is responsible for the physical and logical validity and [https://simplicable.com/new/data-integrity-vs-data-quality integrity of the data] that is used to construct information. It is for this reason that defining and using appropriate processes is essential to ensure high-quality operation, including the development or acquisition, implementation and integration of new or changed capabilities.<br />
The EITBoK details the quality concepts of<br />
* How to approach measuring [http://eitbokwiki.org/Quality#Measuring_Quality Quality]<br />
* The importance of Quality in [http://eitbokwiki.org/Quality#Requirements_Management Requirements Management]<br />
* Understanding an organization’s [http://eitbokwiki.org/Quality#Quality_Capability Quality Capability]<br />
* The differences between [http://eitbokwiki.org/Quality#QMS_and_QC_vs._QA QMS, QC and QA]<br />
* Cost of Quality in [http://eitbokwiki.org/Quality#Technical_Debt_and_the_Cost_of_Rework Technical Debt and the Cost of Rework]<br />
==Disaster Preparedness==<br />
<br />
As explained in the [http://eitbokwiki.org/Disaster_Preparedness EITBOK], disaster preparedness and [http://eitbokwiki.org/Glossary#dr disaster recovery] (DR) support business-continuity planning and include planning for EIT resiliency, as well as recovery from adversity, so that critical business services affected are restored to a satisfactory working state within an [http://eitbokwiki.org/Glossary#acceptable acceptable] timeframe after an event.<br />
The EITBoK devotes a chapter to how the EIT organization and its parent must plan in advance for how it will provide sufficient organizational resilience to recover from disasters and return to normal operation as rapidly as possible.<br />
It provides the following examples of disasters and service interruptions that could occur and should be considered in prevention and recovery planning:<br />
These are examples of disasters:<br />
* Natural disaster affecting datacenters or EIT service operations (flood, fire, earthquake, wind)<br />
* Security breach resulting in a disaster (destruction of data, admin password changes, virus/malware installation, sabotage)<br />
* Usage error (accidental deletion, unplug/turn off system resulting in corruption)<br />
* Utility failure affecting datacenters (loss of power even after UPS)<br />
* Vendor failure (cloud provider security failure, oil spill)<br />
* Staffing issue (employment dispute/walkout, epidemic)<br />
These are examples of unpreparedness:<br />
* Requiring use of computers or printers when power is out<br />
* Requiring use of Internet when power or connectivity is out<br />
* Single point of knowledge/control for administration access<br />
* Lack of offsite backup storage<br />
* Lack of working restoration from backups<br />
* Lack of failover datacenters in separate locations<br />
* Undocumented or out-of-date documentation for system interfaces<br />
*Requiring use of phones that are out of power<br />
* Lack of designation of leaders in restoration efforts (who is in charge of restoring service and they know they are in charge)<br />
* In general, no cohesive, comprehensive EIT service restoration plan<br />
==Operations and Support of Delivered Systems and Services==<br />
[http://eitbokwiki.org/Operations_and_Support Operations and support activities] focus on maintaining an operation normal state in EIT environments, meaning that systems and processes execute according to expectations, with no surprises to users. This desired normal state requires the careful management of EIT assets and services via Operations, as well as of users via Support.<br />
Normal states can be disrupted either by the expected and planned transition of an asset, or by an unexpected event, be it as large as a disaster or by the discovery of a system defect. In the former case, the Disaster Recovery Plan is executed; in the latter, incident management kicks in when a system halts, or problem management is exercised when an operational system is not functioning as expected. The processes needed to ensure effective application of these complex functions is detailed in the [http://eitbokwiki.org/Operations_and_Support#Guiding_Principles Operations and Support Knowledge Area] within the EITBOK. <br />
ISO/IEC/IEEE 20000 may be used by any organization to develop and manage EIT operations, along with the current version of [https://www.servicenow.com ITIL].<br />
ITIL for many is the tool of choice for the operations and infrastructure side of IT, particularly for IT services. <br />
==Ethics==<br />
See the EITBOK’s section on [http://eitbokwiki.org/Ethics ethics] for additional information.<br />
Both the IEEE and ACM require their members to adhere to Codes of Ethics. See the [https://www.ieee.org/about/corporate/governance/p7-8.html IEEE Code of Ethics] and [https://www.acm.org/code-of-ethics ACM Code of Ethics and Professional Conduct]. Both of these can be downloaded freely. In addition, the IEEE Computer Society and the ACM worked together on the [https://dl.acm.org/action/downloadSupplement?doi=10.1145%2F265684.265699&file=acm-se-code-of-ethics.html Software Engineering Code of Ethics] (also available [https://dl.acm.org/doi/10.1145/265684.265699 here]).<br />
The organization should create an easily accessible Code of Ethics:<br />
* Ethical assertions should be documented and socialized in EIT in the form of a Code of Ethics, tied to the overall business code of ethics, and signed off by all staff so that violations can be cause for reprimand or dismissal.<br />
* Vendors should be held to similar ethical standards.<br />
* Lists of employees who have signed off on the Code of Ethics are maintained by EIT governance.<br />
The EITBOK has identified EIT ethical topics that include:<br />
* Those actions and decisions that may be illegal<br />
* Consideration of the social impact of the work at hand—if it will cause harm<br />
* Alignment of business and EIT strategies and policies to an ethical standard<br />
* Incorporation of the ideals of professionalism<br />
* Adherence to applicable regulatory intent<br />
* Protection for whistle blowers<br />
Areas to specifically highlight:<br />
* Activities that interfere with or corrupt the proper function of computers, applications and systems<br />
* Activities that interfere with digital privacy or intellectual rights of others<br />
* Respect for confidentiality, privacy, permissions, and access rights<br />
* Inappropriate bias (skewing) of analysis and reporting<br />
* Inaction in the face of likely ethics violations<br />
==EIT Roles==<br />
Several roles play a part in accomplishing the EIT organization’s mission. Just as a systems engineer can play several roles in a given project, so might several people in an EIT project combine to fulfill the systems engineering function. <br />
The function of EIT systems engineering is to orchestrate systems development, delivery and operation such that the larger organization achieves favorable outcomes in complex environments. Unlike systems projects that are built for known problems, EIT systems may change in unpredictable ways. A primary concern focuses on how quickly systems adapt to change. This entails a type of resiliency based on skills in establishing options and alternative solutions as well as strategies tailored to the volatility of changing needs and available technologies. It also requires expertise in assuring that systems quality is assured from the start.<br />
Different countries, geographic areas and organizations do not always use the same terminology to reference the functions that the roles contributing to systems engineering perform. The following section will provide information about some major international models for defining EIT skills and capabilities. Generally, though, the necessary roles across the product life cycle include these:<br />
* Business Sponsor/Champion<br />
* Enterprise Architect<br />
* Systems Engineer<br />
* Financial Manager<br />
* Application Architect<br />
* Business Analyst and/or Process Analyst<br />
* Data Analyst and/or Data Architect<br />
* Software Engineer and/or Programmer<br />
* Quality Assurance & Testing<br />
* Network Engineer<br />
* Telecoms Engineer<br />
* Integration Expert <br />
* Transition to Operations Manager<br />
* Release Manager<br />
* Availability Manager<br />
* Capacity Manager<br />
* Change Manager<br />
* Configuration Manager<br />
* EIT Operations Manager<br />
* Incident Management<br />
* Problem Manager<br />
* Service Level Manager<br />
* Database Administrator<br />
* Network Manager<br />
* Product Manager<br />
System engineering activities orchestrate the work of these roles so that they function together, rather than in silos or at cross purposes.<br />
==Examples of Systems Engineering in EIT==<br />
Systems Engineering provides a holistic discipline for integrating and managing the contributions of all roles needed to establish and provide EIT products and services. It ensures that a single perspective does not dominate outcomes; instead, it seeks balance among the many disciplines represented above in creating a consistent product or service that meets the interests and needs of enterprise users (and, perhaps, partners). It boils down to common sense, technical sense, knowing when to ask the right questions, and getting the data to support the answers to those questions. System Engineering achieves this via Systems Engineers. In many instances, though, the SE function is accomplished through Project Management approaches using Integrated Product Teams that include technical experts. Thus, although not specifically calling out a Systems Engineering function, the use of IPTs involved the use of SE practices.<br />
A doctoral dissertation from Purdue University performed a survey and causal analysis of project failures and of accidents(Aloisio, 2018). The results were similar to those found in reviews of IBM consulting projects in the 1990s . The following are examples of Systems Engineering interventions that prevented project failures. Almost all point to the lack of the System Engineering balancing act needed for product delivery.<br />
* A widely used document processing product was undergoing a major upgrade. The new VP of Engineering wanted a project review before committing to a schedule. The review showed that the proposed schedule only considered the development effort and did not give sufficient weight to the voices of the testing and documentation organizations, while the needs of the tech support group had been completely overlooked. By establishing an integrated product management team that included technical expertise, as well as expertise in work breakdown and estimating, a realistic effort was defined and the resulting 9-month schedule was met within 3 weeks.<br />
* A Silicon Valley start-up was depending entirely on an offshore development effort to produce its first product. All senior management was in the U.S. The VP of engineering made monthly visits to the development team. The CEO began to feel uneasy about the team’s ability to deliver on schedule sensing that a lot of finger pointing within the development team itself signaled problems. There was no SE or IPT guiding the project. The VP of Engineering seemed unable to sort things out. A project review showed that the probable delivery date was at least 6 months beyond what the CEO was being told. The project was shut down.<br />
* A major player in Human Resource Management had made commitments to deliver a new product. The project involved more than 100 people across the U.S. The delivery date kept slipping. Project roll-out would involve both installation of software and hardware at client sites, as well as installation and staff training at the large, centrally located Client Services organization. Executive Management needed to decide whether to reorganize this very expensive effort or cancel it. Again, the successful solution depended on establishing an effective cross-functional team (IPT) that necessarily included representatives from the technical teams. The IPT was supported by a newly established Project Management Office (PMO). The PMO integrated the geographically disparate efforts by establishing communication channels, as well as common estimating and scheduling practices. The PMO also instituted monthly critical metrics reports to show the IPT bottlenecks and inefficiencies across the project, from development efforts to Client Services set-up to Payroll technical support.<br />
There are far more examples of the lack of systems engineering practices in EIT projects than in their successful use (unfortunately, this seems also to be true in lots of software projects outside of EIT). Systems Engineering provides a holistic discipline for integrating and managing the contributions of all of the roles needed to provide EIT products and services. It ensures that a single perspective does not dominate outcomes.<br />
==Key External Models of EIT Organizational Capability and Maturity==<br />
Because EIT is critical to businesses globally, considerable effort has gone into establishing universal frameworks for EIT skills, along with definitions of levels of capability of each skill. In addition, at least 2 models have been developed for evaluating the organizational performance of EIT. The effectiveness of systems engineering is key to the effectiveness of the EIT organization.<br />
===IT-CMF: IT-Capability Maturity Framework=== <br />
The IT-CMF had its origin in a quality improvement effort at Intel Labs Europe in Ireland. Its intent, as described at the <br />
[https://cio-wiki.org/wiki/IT_Capability_Maturity_Framework_(IT-CMF) CIO Index website] was to quantify and demonstrate the true value impact of IT. IT-CMF is used to measure, develop, and monitor an organization’s EIT capability maturity. It consists of 35 EIT management capabilities organized into four macro capabilities: managing EIT like a business; managing the EIT budget; managing the EIT capability; and managing EIT for business value. Its 35 critical capabilities (CCs) are [http://eitbokwiki.org/Enterprise_IT_Maturity_Assessment described] as “A defined EIT management domain that helps mobilize and deploy EIT-based resources to effect a desired end, often in combination with other resources and capabilities”. <br />
===CMMI: Capability Maturity Model Integration (US)===<br />
The CMMI had its origin in 1987 in a model requested by the U.S. Department of Defense for determining the capability maturity of contractor software development organizations. This became the Capability Maturity Model (CMM). Since then, it has been expanded into a set of Capability Maturity Models, all based on five levels of demonstrably increasing maturity as measured by organization performance. That set was then integrated and became the CMMI. The CMMI set addresses [https://cmmiinstitute.com/dev Development], [https://cmmiinstitute.com/svc Services], [https://cmmiinstitute.com/sm Supplier Management], [https://cmmiinstitute.com/pm People Management], and [https://cmmiinstitute.com/dm Data Management].<br />
===SFIA: Skills Framework for the information Age (Europe, Canada and US)===<br />
The SFIA Framework has been downloaded and used by organizations and individuals in nearly 180 countries. It can be downloaded for free at [https://www.sfia-online.org]. It identifies 97 professional skills across EIT and supporting areas with seven levels of responsibility, which provide generic levels of responsibility, taking into account reflect experience and competency. These describe the behaviors, values, knowledge, and characteristics that an individual should have in order to be considered competent at a particular level.<br />
===E-CF: European Competency Framework (EU)===<br />
The ECF was the first sector-specific implementation of the European Qualifications Framework (EQF). The European Norm (EN) 16234-1 European e-Competence Framework (e-CF) provides a reference of 41 competences as applied at the Information and Communication Technology (ICT) workplace, using a common European reference for competences, skills, knowledge and proficiency levels. The E-CF Explorer web tool is available [https://ecfexplorer.itprofessionalism.org/ online].<br />
===I Competency Dictionary: EIT skills as Defined by METI/ IPA (Japan)===<br />
The Japanese government’s Information-Technology Promotion Agency (IPA), established by the Ministry of Economy, Trade and Industry (METI) developed the ”I Competency Dictionary” (iCD) to support the IT Engineers Examination. It underlies the METI/IPA Skills Standards for IT Professionals, abbreviated as ITSS, established in 2002. ITSS organizes skills within the information services industry into 11 job categories and 35 specialty fields. In each field, there are seven levels of competence based on individual experience and ability to perform. One appealing feature of ITSS is that this standard allows engineers to draw roadmaps for their own futures and career advancement (Career Path). Approximately 90% of large enterprises and over 60% of SMEs in Japan have introduced or are considering using ITSS. Information in English is available at https://www.ipa.go.jp/english/humandev/forth.html.<br />
===ITIL: Information Technology Infrastructure Library===<br />
According to ITLIlibrary.org, the ITIL Open Guide website, “The Information Technology Infrastructure Library (ITIL) defines the organisational structure and skill requirements of an information technology organisation and a set of standard operational management procedures and practices to allow the organisation to manage an IT operation and associated infrastructure. … The [https://www.itlibrary.org/ “library”] itself continues to evolve. This comprises five distinct areas: <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Strategy ITIL Service Strategy]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Design ITIL Service Design]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Transition ITIL Service Transition]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Operation ITIL Service Operation]; and <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Continual_Service_Improvement ITIL Continual Service Improvement].”<br />
It originally grew out of a British government sponsored effort to regularize IT Service Management (ITSM). <br />
==References==<br />
===Works Cited===<br />
Fong, E.N. and A.H. Goldfine. 1989. ''Information Management Directions: The Integration Challenge. '' National Institute of Standards and Technology (NIST) Special Publication 500-167, September 1989. https://csrc.nist.rip/library/NIST%20SP%20500-167.pdf <br />
<br />
Hammer, M., T.H. Davenport and J. Champy. 1986. ''Dispersion and Interconnection: Approaches to Distributed Systems Architecture'', Cambridge, MA: CSC Index Inc. and Hammer and Company, Inc. (June 1986). Available as: https://www.globalaea.org/general/custom.asp?page=Resources <br />
<br />
Hilliard, R. 2015. “Lessons from the fundamental unity of architecting”. ''Software Engineering in the Systems Context'', editors: Ivar Jacobson and Harold 'Bud' Lawson.<br />
<br />
Hofmeister, C. et al. 2007. “A general model of software architecture design derived from five industrial approaches”. ''The Journal of Systems and Software'' 80(1). <br />
<br />
ISO/IEC 25010:2011 ''Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models'', 4.2.3.2.<br />
<br />
ISO/IEC/IEEE 42010 Users Group. ''Survey of Architecture Frameworks'' Available as: http://www.iso-architecture.org/42010/afs/<br />
<br />
ISO/IEC/IEEE. 2011. ISO/IEC/IEEE 42010:2011, ''Systems and software engineering — Architecture description. ''<br />
<br />
PMI. 2013. ''Software Extension to PMBOK® Guide – Fifth Edition. '' Newtown Square, PA, USA: Project Management Institute (PMI). Available as: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/software-extension-5th-edition.<br />
<br />
Rivera, R. 2013. “The PRISM Architecture Framework – Was it the Very First Enterprise Architecture Framework?” ''Journal of Enterprise Architecture'', November 2013<br />
<br />
Zachman, J. 1987. “A Framework for Information Systems Architecture”. ''IBM Systems Journal'', pp454-470, 1987 <br />
<br />
===Primary References===<br />
IEEE Computer Society. ''Enterprise IT Body of Knowledge''. Available: http://eitbokwiki.org<br />
<br />
=-=Additional References===<br />
IT Capability Maturity Framework (IT-CMF): The Body of Knowledge Guide. 2015. Editors. Martin Curley, Jim Kenneally, Marian Carcary. Van Haren Publishing.<br />
<br />
Lessons from Systems Engineering Failures: Determining Why Systems Fail, The State of Systems Engineering Education, and Building an Evidence-Based Network to Help Systems Engineers Identify and Fix Problems on Complex Projects, Diane Constance Aloisio, December 2018.<br />
<br />
===International Standards Guiding EIT===<br />
ANSI/AIAA. 2012. ''ANSI/AIAA Guide to the Preparation of Operational Concept Documents. '' ANSI/AIAA G-043A-2012e.<br />
<br />
IEEE 2012 Std 828™-2012, ''IEEE Standard for Configuration Management in Systems and Software Engineering. ''<br />
<br />
ISO 10004:2012, Quality management—Customer satisfaction—Guidelines for monitoring and measuring<br />
<br />
ISO 10007:2003, Quality management systems—Guidelines for configuration management<br />
<br />
ISO 18238:2015, Space systems—Closed loop problem solving management<br />
<br />
ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models<br />
<br />
ISO/IEC 16350:2015, Information technology—Systems and software engineering—Application management<br />
<br />
ISO/IEC 19770-1:2012, Information technology—Software asset management—Part 1: Processes and tiered assessment of conformance<br />
<br />
ISO/IEC 20000-1:2011, (IEEE Std 20000-1:2013) Information technology—Service management—Part 1: Service management system requirements<br />
<br />
ISO/IEC 20000–2:2012, Information technology—Service management—Part 2: Guidance on the application of service management systems<br />
<br />
ISO/IEC TR 20000–10:2015, Information technology—Service management—Part 10: Concepts and terminology<br />
<br />
ISO/IEC TR 20000–11:2015, Information technology—Service management—Part 11: Guidance on the relationship between ISO/IEC 20000-1:2011 and related frameworks: ITIL®<br />
<br />
ISO/IEC TR 20000-12—Information technology—IT Service management—Part 12: Guidance on the relationship between ISO/IEC 20000-1:2011 and service management frameworks: CMMI-SVC®<br />
<br />
ISO/IEC/IEEE 14764-2006, Software Engineering—Software Lifecycle Processes—Maintenance<br />
<br />
ISO/IEC 15939:2007, Systems and software engineering—Measurement process<br />
<br />
ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description <br />
<br />
<br />
----<br />
<center>[[ Systems Engineering and Economics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Quality Attributes|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Enterprise_IT&diff=66942
Systems Engineering and Enterprise IT
2023-05-07T03:57:35Z
<p>Mhaas: </p>
<hr />
<div>----<br />
'''''Lead Authors:''''' Chuck Walrad and Richard Hilliard<br />
----<br />
This article forms part of the [[Related Disciplines]] knowledge area (KA). It discusses enterprise IT, building upon the concepts and practices of Systems Engineering presented elsewhere in the SEBOK. Systems Engineering is integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of ''engineered technical systems''. <br />
<br />
== Enterprise IT Introduction==<br />
Although it had its origin in the need to improve success rates in U.S. Government outsourcing of technical systems, Systems Engineering is also integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of [https://www.incose.org/about-systems-engineering/system-and-se-definition/systems-engineering-definition#ENGINEERED_SYSTEM engineered technical systems].<br />
Examples of EIT systems include enterprise resource planning, supply chain management and customer relationship management systems, accounting, finance, inventory and order management, marketing, planning, purchasing, and sales.<br />
In the late 1980s and throughout the 1990s, EIT organizations became increasingly aware that the success rates of IT projects were very low, and that their enterprise customers were increasingly unhappy with their EIT investments. The Standish Group sought to understand what was going on. Their findings were presented in the [https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf Chaos Report] (1994):<br />
The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable but could easily be in the trillions of dollars.<br />
As a result, commercial IT organizations, through the auspicious parallel emergence of the Total Quality Management movement and the increasingly widespread development of application development methodologies (ADM) by IT management consulting firms, recognized the need for the principles of Systems Engineering and cross-functional teams (Integrated Product Teams [https://www.sebokwiki.org/wiki/Integrated_Product_Team_(IPT)_(glossary)]. It should be noted that there is considerable overlap today between what constitutes Systems Engineering and what constitutes [[Portfolio Management|Relationships between Systems Engineering and Project Management]] (see [https://www.pmi.org/learning/library/bridging-gap-program-management-systems-engineering-6213 PMI]). This article does not attempt to resolve this issue. Note that the “[[Related Business Activities|following business management activities]] can be ''supported'' by enterprise systems engineering (ESE) activities” [emphasis added]: <br />
* mission and strategic planning,<br />
* business processes and information management,<br />
* performance management,<br />
* portfolio management,<br />
* resource allocation and budgeting, and<br />
* program and project management.<br />
Note that these same areas have been designated as being supported by Project Management Offices. However, since a key difference between project management and systems engineering has been identified as the requirement that the latter includes technical expertise in the product/system of concern, focus should be on systems engineering and integrated product teams (IPTs). <br />
With IPTs, each product is shepherded from concept through delivery and support to retirement by a cross-functional team that includes representatives from each area of responsibility, such as customer requirements development, design and development, test, configuration management, release engineering, delivery, and support.<br />
As enterprises have come to depend more and more on technology to perform effectively, Enterprise IT organizations have matured, often due to the influence of IT consulting firms that make it their business to keep abreast of best practices.<br />
<br />
== EIT Concepts ==<br />
This knowledge area (KA) discusses enterprise IT, building upon the concepts elucidated in the IEEE/ACM ''[http://eitbokwiki.org EITBOK Guide to the Enterprise Information Technology Body of Knowledge]'' and general concepts of Systems Engineering elsewhere in SEBOK. <br />
An enterprise may be viewed from various perspectives: such as a system or a [[system of systems (SoS)|Enterprise Systems Engineering]]:<br />
* system-like enterprise: enterprises, like other systems, may have a tight coupling, single-executive function; <br />
* system of systems-like enterprise: may be a loosely coupled group of organizations with blurred boundaries and (yet) with (some) shared outcomes.<br />
The choice of perspective may vary with many factors: the enterprise itself, the mission or purpose, or the particular engineering task at hand. We can view an enterprise as a system with inputs and outputs in relation to the outside world, or a system of systems interacting through their individual inputs and outputs. <br />
An enterprise usually involves one (or more) organization(s) but need not be identified with the organization. As the scope of human and organizational participants of the enterprise widen, there may be no single point of control. For example, an ''extended enterprise'' could include a company, its suppliers and customers.<br />
Whatever perspective (system-like, SoS-like, other) is taken there are [[key ingredients|Enterprise Systems Engineering Background]] of any enterprise: capabilities, individual (competencies) and the organizational design. [[Capabilities|Enterprise Capability Management]] can be further categorized: “There are three different kinds of capability: organizational capability, system capability, and operational capability.” These capabilities determine what the enterprise is able to produce which may be external offerings or internal mechanisms. Operational capabilities create services and/or products which in turn produce value as determined by stakeholders. The capabilities of an enterprise are realized through [[Enterprise Systems Engineering Background|various enterprise elements]], including: “hardware, software, personnel, facilities, data, materials, techniques, and even services”. which include “soft” items, like people, processes, principles, policies, practices, organizations, doctrine, theories, and beliefs.<br />
EIT capabilities exist through lifecycles spanning from creation through eventual replacement and disposal. ''Life cycle models'' are schemes to aid in the understanding, design, planning and management of the capability of interest. <br />
“A life cycle for a system generally consists of a series of stages regulated by a set of management decisions which confirm that the system is mature enough to leave one stage and enter another.” Basic life cycle terms and concepts are discussed in [[System Lifecycle Approaches]]. Some typical life cycles are discussed in [[System Lifecycle Models]].<br />
A life cycle-based approach can be deployed across the several levels and used to manage evolution. These levels are:<br />
* the enterprise itself,<br />
* the processes and organizations constituting the enterprise,<br />
* the systems enabling the capabilities, services or products provided. <br />
It is important to distinguish between ''product'' and ''project'' lifecycle models. A product’s life cycle extends from its initial concept approval, through development and distribution, to its retirement. This is the cycle that is managed within an Enterprise IT organization, since EIT must manage the hardware or software product from its introduction, in the case of acquired capabilities, or from its concept approval and development, in the case of capabilities it builds, through its deployment, maintenance and eventual retirement (withdrawal). Each of these stages is usually managed as a project or a series of projects.<br />
However, most discussions of life cycles within software and systems discussions focus on ''project'' life cycles. See, for example, the ''Software Extension to PMBOK Guide'' (PMI 2013).<br />
==System of Systems Context in EIT==<br />
“Enterprise IT” (EIT) is used both to refer to the technology organization/business unit within the enterprise and to the enterprise’s information technology systems. In this article, we use EIT to refer to the technology systems. When referring to the organization, we use the phrase “Enterprise IT organization” or EIT organization. <br />
Enterprise IT organizations are responsible for complex socio-technical systems. Socio-technical systems in a business context (thus, EIT) contain technical elements (software, hardware, networks, storage, databases, etc.) but they also contain essential human components and necessary business processes. As covered in [[Introduction to Systems Engineering Fundamentals]], they exist in an engineered System Context that is a set of system component interrelationships within a real-world environment:<br />
This includes where problems come from and how they are defined, how we identify and select candidate solutions, how to balance technology and human elements in the wider solution context, how to manage the complex organizational systems needed to develop new solutions, and how developed solutions are used, sustained and disposed of. … Systems Engineering should consider the full Engineered System Context so that the necessary understanding can be reached and the right systems engineering decisions can be made. <br />
Socio-technical systems also have the following key characteristics: ''Openness'' in that they strongly interact with their environments, and ''unfinished'' in that they evolve over time.<br />
A complex of EIT systems is essential to the successful functioning of the humans in the enterprise. They rely on EIT’s technology for communication, for paying employees, for people management, for business measurement, and often for managing supply chains. Thus, “EIT needs to be viewed as a strategic partner to all the other functions and business units within an enterprise. This means that the results produced by EIT along with its effectiveness and efficiency are all critically important to the success of the enterprise.” [http://eitbokwiki.org/What_is_the_Enterprise_Perspective%3F]<br />
To accomplish this mission, the EIT organization builds and acquires new systems or system components, integrates them into the mega System of Systems, and maintains the integrity and interoperability of the individual components, but also the integrity of the entire complex of systems. In addition, security and performance levels must be achieved, benchmarked and maintained or improved.<br />
==Major concerns of the EIT Organization==<br />
The [http://eitbokwiki.org ''Enterprise IT Body of Knowledge''] provides a good deal of information about these major concerns, which we will not replicate here. Rather, links to the relevant areas are provided. The EITBOK demonstrates how, in providing technology systems and services to the enterprise, the EIT organization must skillfully manage such concerns as the following.<br />
<br />
===Enterprise Architecture===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Enterprise_Architecture Enterprise Architecture] for additional information. ''<br />
[http://eitbokwiki.org/Glossary#ea ''Enterprise architecture''] (EA) is the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. EA applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their organization's strategies. Enterprise architecture builds upon many of the concepts and practices of [[System Architecture Definition|systems architecture]] and also software architecture [https://www.sebokwiki.org/wiki/System_Architecture_Definition].<br />
This section will discuss Enterprise Architecture from the perspective of key [[Principles of Systems Thinking]], designated in this article with '''''bold italics'''''. There are many commonalities in architecture whether one is architecture systems, software or the enterprise [Unity]. In this article we highlight both commonalities and differences between Enterprise Architecture and Systems Architecture. <br />
Architecture takes place at the juncture of design problems and their solutions. Design problems rarely arrive fully formulated or “hatched” for the architect; much of the architecture effort is to analyze or formulate the problems to be solved. Often this involves negotiation both within the enterprise and with outside stakeholders. Possible solutions are limited by resources and schedule and therefore often must also be negotiated.<br />
A dominant principle of Enterprise Architecture is '''''separation of concerns''''' (SoC). This is due to the complexity of enterprises, with many forces acting upon them; the many technologies and disciplines involved in their creation and day-to-day operations; and due to the diversity of stakeholders involved in the enterprise (see [[EIT Roles]]). <br />
An application of SoC is the '''''boundary''''' principle which is crucial to separate what is “inside” the enterprise from what is “outside”. While the former is often under the enterprise’s control, the latter is often beyond its control. <br />
For some systems, determining the boundary is a key decision, subject to many possibilities and consequences. This is perhaps less the case for enterprises whose bounds are determined by the extent of organizations, regulations, supply chains or other criteria. Within an established boundary, the '''''holism''''' principle applies: to treat the enterprise as a unified whole, and, in particular, with respect to the '''''interaction''''' of the enterprise with its ''environment''—including stakeholders, other enterprises and systems. From an enterprise IT perspective, an enterprise is a ''system of systems. '' SoC offers a way to focus on the constituent systems in terms of their interconnections to one another to form the enterprise.<br />
Another useful application of SoC is to apply the principle of '''''multiple views''''' to depict the architecture of the enterprise in different ways to address the diverse interests (i.e., ''concerns'') of an enterprise’s various stakeholders. Each ''architecture view'' presents a specific perspective on the enterprise. To be understandable to its audiences (those various stakeholders), each view should follow the conventions of its ''architecture viewpoint'' (ISO/IEC/IEEE 42010 2011). Just as a map should have a legend, each view should have a documented viewpoint providing a prescribed set of conventions for looking at the enterprise through the resulting view. A viewpoint definition serves as a contract between the architect and stakeholders on ''how'' a selected set of concerns are to be addressed. Each viewpoint allows the architect to consider the enterprise in terms of various kinds of elements and relations among them and to present that view to those “concerned” stakeholders. Dominating concerns in enterprise architecture include interoperability, quality of systems and services, operations, managing change, and alignment with the enterprise’s mission, market, and technology. Via the principle of '''''dualism''''', we recognize that some viewpoints are paired, such as with process/data duality. Another pervasive duality in the enterprise is of people/technology in terms of what capabilities are automated and which are performed by people.<br />
In support of enterprise architecture, there are numerous ''enterprise architecture frameworks'' each providing a pre-defined, integrated set of viewpoints to frame typical, recurring concerns (ISO/IEC/IEEE 42010 Users Group 2022). The earliest recorded framework was (Hammer et al. 1986), developed in the mid-1980s in response to growing availability of distributed computing to the enterprise (Rivera 2013). In the late 1980s, US NIST created its Enterprise Architecture Model as a guide for US federal departments to organize their IT offerings (Fong and Goldfine 1989). NIST’s 5-layer model remains influential today. Despite never using the term “enterprise,” Zachman’s information systems architecture has had a major influence on how subsequent frameworks have been organized and depicted using grids or cubes. Later frameworks have evolved in response to emerging concepts, such as the move from client-server to service-oriented applications, as in the OASIS SOA Reference Model and its associated framework. The 1990s saw a proliferation of frameworks for defense enterprises including US DODAF, UK MODAF, NATO’s NAF and led to successors such as OMG’s UAF.<br />
Yet another application of '''''separation of concerns''''' is distinguishing today’s needs versus facilitating future needs; balancing '''''stability/change''''' and highlighting the temporal planning aspect of architecture of the enterprise. In concert with applying SOC, the architect uses the principle of '''''abstraction''''' to “forget” some details of the subject and thus focus on essentials. Just as SoC is a way of taking things apart, '''''abstraction''''' is a way of unifying or putting like things together through generalization. These two principles are perhaps the most central to architecture. SoC and abstraction work together: SoC picks out subjects and abstraction helps architects to focus upon the essentials of each subject. <br />
Returning to the '''''boundary''''' and '''''holism''''' principles, the enterprise architect applies these recursively. As architecting proceeds, the internal details of the enterprise become known in terms of '''''interaction''''' among its parts and other '''''relations'''''. Again, '''''multiple views''''' are used to factor specific '''''relations'''''into distinct views. Typical relations include Causality, Dependency, Client-Server, and Input-Output. <br />
There are a variety of ways to structure the enterprise based upon stakeholder needs, mission or charter, technologies or capabilities already in place. Among these are structuring principles including: <br />
* '''''Modularity''''' (separate and group capabilities into modules by commonalities); <br />
* '''''Network''''' (modules are linked together); <br />
* '''''Encapsulation''''' (separating architecture modules use from how they are implemented); <br />
* '''''Layer Hierarchy''''' (separation through gradual refinement); <br />
* ''''' Regularity''''' (uniformity of interactions, of structure within layer, within network). <br />
* ''''' Similarity/Difference''''' (recognizing the limits of Regularity)<br />
A simple pattern for architecture has been defined (Hofmeister ''et al. '' 2007). Its elements are Analysis, Synthesis and Evaluation. See Figure 1 below. <br />
''Architecture Analysis'' formulates architecturally-significant requirements (ASRs)—those requirements which influence an enterprise’s architecture. Architecture analysis is based on identified concerns and other information based on understanding the enterprise’s environment, known requirements, stakeholder needs and any constraints. ASRs reflect the “design problems” that the architecture must solve. In many cases, negotiations take place to modify incoming needs, requirements and expectations to make solutions possible. The result of this activity takes the form of ASRs, including architecture principles and initial enterprise-wide decisions.<br />
''Architecture Synthesis'' develops candidate solutions in response to the concerns and ASRs. During Synthesis the architect works out the details of solutions to the identified design problems, tradeoff and interactions between them which are likely to generate further design problems. Synthesis elaborates the ASRs, principles and initial decisions into more detailed solution elements. The principle of ''''' EQUIFINALITY''''' reminds us that for many stable situations (i.e., states of the enterprise), there are many ways to reach those states.<br />
''Architecture Evaluation'' validates whether chosen solutions satisfy ASRs or whether rework is needed (ISO/IEC/IEEE 42030 2019).<br />
Applying the principles discussed above is pervasive in enacting the Analysis–Synthesis–Evaluation pattern iteratively. <br />
<br />
[[File:EIT Figure 1 - Higher Resolution.png|centre|thumb|1000px|'''Figure 1. A pattern for Architecture.''']]<br />
<br />
While there are many commonalities among EIT, systems and software architectures, Figure 2 addresses the relationships ''between'' them. Viewing an enterprise as a system, the EIT architecture governs the fundamental IT decisions of the enterprise. That enterprise might be extended to “outsiders” such as vendors, suppliers and perhaps customers. Depending upon the enterprise, the ''governs'' relationship may entail very strict rules or loose guidance. <br />
Within the enterprise, the ecosystem of systems, applications and data may be viewed as a system of systems. The EIT Architecture constrains the architectures governing individual systems, applications and data stores within the enterprise, so that these are able to interoperate and otherwise “play nicely” together.<br />
<br />
[[File:EIT Figure 2.png|centre|thumb|1000px|'''Figure 2. Relating Enterprise IT, Systems and Software Architecture.''']] <br />
<br />
===Strategy and Governance===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance] for additional information. ''<br />
<blockquote><br />
[http://eitbokwiki.org/Glossary#eit Enterprise information technology] (EIT) governance is the established process of defining the strategy for the EIT organization and overseeing its execution to achieve enterprise goals. Strategic planning translates the larger enterprise’s goals into EIT goals and defines what EIT must do to achieve those goals. This effort then communicates this hierarchy of goals: EIT goals as well as how they support the enterprise’s goals. EIT governance drives needed changes to achieve those goals, while maintaining agreed levels of operation. Taking into account various perspectives (such as financial, historical, environmental, and future projections), a strategic plan is a roadmap for action and change, both vertically and horizontally, across the EIT organization. The EIT organization’s strategic plans are based on the enterprise’s strategic plans, focusing on EIT’s role in them; EIT governance provides a monitoring and control framework to achieve strategic goals and objectives. Thus, EIT governance is essential for achieving the EIT strategy and goals..<br />
-[http://eitbokwiki.org/Strategy_and_Governance EITBOK wiki]<br />
</blockquote><br />
<br />
The principle of ''''' PARSIMONY''''' applies here, too (see [[Principles of Systems Thinking]]). These principles will be designated in this article with '''''bold italics'''''. For example, the simplest possible measurement and reporting systems are most likely to be used and not corrupted. Similarly, the EIT organizational structure should be straightforward and easy to traverse so that staff can communicate and problem-solve in teams.<br />
In governing the EIT organization to meet its dual goals of satisfying its customers and meeting its budget and schedule commitments, EIT management encounters the difficulty of managing in the face of '''''dualism''''', “ensuring a constant dynamic balance often through a cyclic dominance of one element and then the other”. The most obvious instance of handling ''''' dualism''''' in EIT is the trade-off between budget, project prioritization and features within projects.<br />
===Change===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Change_Initiatives Change Initiatives] for more information. ''<br />
There are two levels of change management discussed in the EITBOK: organizational change management and changes to the IT organization’s assets, whether they be software, hardware, or telecommunications systems.<br />
In the larger sense, the introduction of new systems and services often also requires changes in people’s jobs and in the processes used to accomplish those jobs. Such efforts are intended to increase business value. Such changes require change initiatives because they involve guiding a mixture of stakeholders through the change process. This is one aspect of [http://eitbokwiki.org/Change_Initiatives change management].<br />
Change also occurs when existing systems or services must be updated to meet new needs. Depending on the scope of the proposed changes, a change initiative may be required in this situation, too. At any rate, a change request process must be initiated and tracked to disposition (deferral, rejection, or implementation). Changes also come about as a result of defect reports. In such cases, the defect report must be tracked throughout the report’s life cycle, to disposition (deferral, rejection, or implementation).<br />
These latter types of change management are discussed in detail in the EITBOK’s section on [http://eitbokwiki.org/Operations_and_Support Operations and Support].<br />
===Interoperability of Component Systems===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Interoperability interoperability] for more information. ''<br />
As explained in the [http://eitbokwiki.org/Interoperability#One EITBOK], ''interoperability'' means “the ability of systems (including organizations) to exchange and use exchanged information without knowledge of the characteristics or inner workings of the collaborating systems (or organizations).” This definition is based on an ISO definition: “degree to which two or more systems, products, or components can exchange information and use the information that has been exchanged.” (ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models, 4.2.3.2. ) Note that this definition includes hardware components as well as software systems and the organizations in which they are used.<br />
Because technology changes so rapidly, and organizations themselves are frequently changing, achieving and maintaining interoperability is crucial. It is one of the main reasons that providing IT services is difficult and how it differs from engineering and delivering finished products, whether off-the-shelf products or bespoke systems.<br />
===Security of Systems and Data===<br />
<blockquote><br />
There are only two types of companies: those that have been hacked, and those that will be.<br />
-FBI Director Robert Mueller, October 2012<br />
</blockquote><br />
<br />
<blockquote><br />
There are two kinds of big companies in the United States. There are those who've been hacked by the Chinese and those who don't know that they've been hacked by the Chinese<br />
-FBI Director James Comey, October 2014<br />
</blockquote><br />
''See the EITBOK’s section on [http://eitbokwiki.org/Security security] for additional information. ''<br />
While there are many definitions for security, most include the three dimensions of confidentiality, integrity, and availability (sometimes referred to as the [http://eitbokwiki.org/Glossary#ciatriad CIA triad]). As such, the primary goal of EIT security is to preserve the confidentiality, integrity, and availability of information and information systems. <br />
The principles behind an organization’s [http://eitbokwiki.org/Glossary#isms information security management system] (ISMS) should be to design, implement, and maintain a coherent set of policies, processes, and systems that keep the risks associated with its information assets at a tolerable level, and yet, manage the cost and inconvenience of said risk management. As such, the goals of EIT security are to:<br />
* Always understand the current risk tolerance of the enterprise with respect to information and device security.<br />
* Understand the security threats and potential damages to information, devices, and individuals.<br />
* Create and follow policies and procedures that keep cyberattack risk and damages at or below a tolerable level.<br />
* Effectively and efficiently detect and deal with<br />
[http://eitbokwiki.org/Security#One cyberattack incidents].<br />
Ensuring security in EIT has been made even more pressing and more difficult by the proliferation of mobile devices in enterprises and their ever-increasing use to conduct business. Increasingly, personal devices (Bring Your Own Device – BYOD) are used, accessing both corporate networks and public networks. The cost of [https://www.checkpoint.com/downloads/products/check-point-mobile-security-survey-report2013.pdf mobile security incidents] very easily can outweigh the cost of the mobile device itself. <br />
==Quality of Systems and Services==<br />
The Enterprise ''Information'' Technology organization has, since its origins, had as its primary responsibility the timely provision of information to the larger organization. The information is expected to be not only timely, but also accurate and relevant. While the EIT organization itself may not be responsible for creating the data, it is responsible for the physical and logical validity and [https://simplicable.com/new/data-integrity-vs-data-quality integrity of the data] that is used to construct information. It is for this reason that defining and using appropriate processes is essential to ensure high-quality operation, including the development or acquisition, implementation and integration of new or changed capabilities.<br />
The EITBoK details the quality concepts of<br />
* How to approach measuring [http://eitbokwiki.org/Quality#Measuring_Quality Quality]<br />
* The importance of Quality in [http://eitbokwiki.org/Quality#Requirements_Management Requirements Management]<br />
* Understanding an organization’s [http://eitbokwiki.org/Quality#Quality_Capability Quality Capability]<br />
* The differences between [http://eitbokwiki.org/Quality#QMS_and_QC_vs._QA QMS, QC and QA]<br />
* Cost of Quality in [http://eitbokwiki.org/Quality#Technical_Debt_and_the_Cost_of_Rework Technical Debt and the Cost of Rework]<br />
==Disaster Preparedness==<br />
<br />
As explained in the [http://eitbokwiki.org/Disaster_Preparedness EITBOK], disaster preparedness and [http://eitbokwiki.org/Glossary#dr disaster recovery] (DR) support business-continuity planning and include planning for EIT resiliency, as well as recovery from adversity, so that critical business services affected are restored to a satisfactory working state within an [http://eitbokwiki.org/Glossary#acceptable acceptable] timeframe after an event.<br />
The EITBoK devotes a chapter to how the EIT organization and its parent must plan in advance for how it will provide sufficient organizational resilience to recover from disasters and return to normal operation as rapidly as possible.<br />
It provides the following examples of disasters and service interruptions that could occur and should be considered in prevention and recovery planning:<br />
These are examples of disasters:<br />
* Natural disaster affecting datacenters or EIT service operations (flood, fire, earthquake, wind)<br />
* Security breach resulting in a disaster (destruction of data, admin password changes, virus/malware installation, sabotage)<br />
* Usage error (accidental deletion, unplug/turn off system resulting in corruption)<br />
* Utility failure affecting datacenters (loss of power even after UPS)<br />
* Vendor failure (cloud provider security failure, oil spill)<br />
* Staffing issue (employment dispute/walkout, epidemic)<br />
These are examples of unpreparedness:<br />
* Requiring use of computers or printers when power is out<br />
* Requiring use of Internet when power or connectivity is out<br />
* Single point of knowledge/control for administration access<br />
* Lack of offsite backup storage<br />
* Lack of working restoration from backups<br />
* Lack of failover datacenters in separate locations<br />
* Undocumented or out-of-date documentation for system interfaces<br />
*Requiring use of phones that are out of power<br />
* Lack of designation of leaders in restoration efforts (who is in charge of restoring service and they know they are in charge)<br />
* In general, no cohesive, comprehensive EIT service restoration plan<br />
==Operations and Support of Delivered Systems and Services==<br />
[http://eitbokwiki.org/Operations_and_Support Operations and support activities] focus on maintaining an operation normal state in EIT environments, meaning that systems and processes execute according to expectations, with no surprises to users. This desired normal state requires the careful management of EIT assets and services via Operations, as well as of users via Support.<br />
Normal states can be disrupted either by the expected and planned transition of an asset, or by an unexpected event, be it as large as a disaster or by the discovery of a system defect. In the former case, the Disaster Recovery Plan is executed; in the latter, incident management kicks in when a system halts, or problem management is exercised when an operational system is not functioning as expected. The processes needed to ensure effective application of these complex functions is detailed in the [http://eitbokwiki.org/Operations_and_Support#Guiding_Principles Operations and Support Knowledge Area] within the EITBOK. <br />
ISO/IEC/IEEE 20000 may be used by any organization to develop and manage EIT operations, along with the current version of [https://www.servicenow.com ITIL].<br />
ITIL for many is the tool of choice for the operations and infrastructure side of IT, particularly for IT services. <br />
==Ethics==<br />
See the EITBOK’s section on [http://eitbokwiki.org/Ethics ethics] for additional information.<br />
Both the IEEE and ACM require their members to adhere to Codes of Ethics. See the [https://www.ieee.org/about/corporate/governance/p7-8.html IEEE Code of Ethics] and [https://www.acm.org/code-of-ethics ACM Code of Ethics and Professional Conduct]. Both of these can be downloaded freely. In addition, the IEEE Computer Society and the ACM worked together on the [https://dl.acm.org/action/downloadSupplement?doi=10.1145%2F265684.265699&file=acm-se-code-of-ethics.html Software Engineering Code of Ethics] (also available [https://dl.acm.org/doi/10.1145/265684.265699 here]).<br />
The organization should create an easily accessible Code of Ethics:<br />
* Ethical assertions should be documented and socialized in EIT in the form of a Code of Ethics, tied to the overall business code of ethics, and signed off by all staff so that violations can be cause for reprimand or dismissal.<br />
* Vendors should be held to similar ethical standards.<br />
* Lists of employees who have signed off on the Code of Ethics are maintained by EIT governance.<br />
The EITBOK has identified EIT ethical topics that include:<br />
* Those actions and decisions that may be illegal<br />
* Consideration of the social impact of the work at hand—if it will cause harm<br />
* Alignment of business and EIT strategies and policies to an ethical standard<br />
* Incorporation of the ideals of professionalism<br />
* Adherence to applicable regulatory intent<br />
* Protection for whistle blowers<br />
Areas to specifically highlight:<br />
* Activities that interfere with or corrupt the proper function of computers, applications and systems<br />
* Activities that interfere with digital privacy or intellectual rights of others<br />
* Respect for confidentiality, privacy, permissions, and access rights<br />
* Inappropriate bias (skewing) of analysis and reporting<br />
* Inaction in the face of likely ethics violations<br />
==EIT Roles==<br />
Several roles play a part in accomplishing the EIT organization’s mission. Just as a systems engineer can play several roles in a given project, so might several people in an EIT project combine to fulfill the systems engineering function. <br />
The function of EIT systems engineering is to orchestrate systems development, delivery and operation such that the larger organization achieves favorable outcomes in complex environments. Unlike systems projects that are built for known problems, EIT systems may change in unpredictable ways. A primary concern focuses on how quickly systems adapt to change. This entails a type of resiliency based on skills in establishing options and alternative solutions as well as strategies tailored to the volatility of changing needs and available technologies. It also requires expertise in assuring that systems quality is assured from the start.<br />
Different countries, geographic areas and organizations do not always use the same terminology to reference the functions that the roles contributing to systems engineering perform. The following section will provide information about some major international models for defining EIT skills and capabilities. Generally, though, the necessary roles across the product life cycle include these:<br />
* Business Sponsor/Champion<br />
* Enterprise Architect<br />
* Systems Engineer<br />
* Financial Manager<br />
* Application Architect<br />
* Business Analyst and/or Process Analyst<br />
* Data Analyst and/or Data Architect<br />
* Software Engineer and/or Programmer<br />
* Quality Assurance & Testing<br />
* Network Engineer<br />
* Telecoms Engineer<br />
* Integration Expert <br />
* Transition to Operations Manager<br />
* Release Manager<br />
* Availability Manager<br />
* Capacity Manager<br />
* Change Manager<br />
* Configuration Manager<br />
* EIT Operations Manager<br />
* Incident Management<br />
* Problem Manager<br />
* Service Level Manager<br />
* Database Administrator<br />
* Network Manager<br />
* Product Manager<br />
System engineering activities orchestrate the work of these roles so that they function together, rather than in silos or at cross purposes.<br />
==Examples of Systems Engineering in EIT==<br />
Systems Engineering provides a holistic discipline for integrating and managing the contributions of all roles needed to establish and provide EIT products and services. It ensures that a single perspective does not dominate outcomes; instead, it seeks balance among the many disciplines represented above in creating a consistent product or service that meets the interests and needs of enterprise users (and, perhaps, partners). It boils down to common sense, technical sense, knowing when to ask the right questions, and getting the data to support the answers to those questions. System Engineering achieves this via Systems Engineers. In many instances, though, the SE function is accomplished through Project Management approaches using Integrated Product Teams that include technical experts. Thus, although not specifically calling out a Systems Engineering function, the use of IPTs involved the use of SE practices.<br />
A doctoral dissertation from Purdue University performed a survey and causal analysis of project failures and of accidents(Aloisio, 2018). The results were similar to those found in reviews of IBM consulting projects in the 1990s . The following are examples of Systems Engineering interventions that prevented project failures. Almost all point to the lack of the System Engineering balancing act needed for product delivery.<br />
* A widely used document processing product was undergoing a major upgrade. The new VP of Engineering wanted a project review before committing to a schedule. The review showed that the proposed schedule only considered the development effort and did not give sufficient weight to the voices of the testing and documentation organizations, while the needs of the tech support group had been completely overlooked. By establishing an integrated product management team that included technical expertise, as well as expertise in work breakdown and estimating, a realistic effort was defined and the resulting 9-month schedule was met within 3 weeks.<br />
* A Silicon Valley start-up was depending entirely on an offshore development effort to produce its first product. All senior management was in the U.S. The VP of engineering made monthly visits to the development team. The CEO began to feel uneasy about the team’s ability to deliver on schedule sensing that a lot of finger pointing within the development team itself signaled problems. There was no SE or IPT guiding the project. The VP of Engineering seemed unable to sort things out. A project review showed that the probable delivery date was at least 6 months beyond what the CEO was being told. The project was shut down.<br />
* A major player in Human Resource Management had made commitments to deliver a new product. The project involved more than 100 people across the U.S. The delivery date kept slipping. Project roll-out would involve both installation of software and hardware at client sites, as well as installation and staff training at the large, centrally located Client Services organization. Executive Management needed to decide whether to reorganize this very expensive effort or cancel it. Again, the successful solution depended on establishing an effective cross-functional team (IPT) that necessarily included representatives from the technical teams. The IPT was supported by a newly established Project Management Office (PMO). The PMO integrated the geographically disparate efforts by establishing communication channels, as well as common estimating and scheduling practices. The PMO also instituted monthly critical metrics reports to show the IPT bottlenecks and inefficiencies across the project, from development efforts to Client Services set-up to Payroll technical support.<br />
There are far more examples of the lack of systems engineering practices in EIT projects than in their successful use (unfortunately, this seems also to be true in lots of software projects outside of EIT). Systems Engineering provides a holistic discipline for integrating and managing the contributions of all of the roles needed to provide EIT products and services. It ensures that a single perspective does not dominate outcomes.<br />
==Key External Models of EIT Organizational Capability and Maturity==<br />
Because EIT is critical to businesses globally, considerable effort has gone into establishing universal frameworks for EIT skills, along with definitions of levels of capability of each skill. In addition, at least 2 models have been developed for evaluating the organizational performance of EIT. The effectiveness of systems engineering is key to the effectiveness of the EIT organization.<br />
===IT-CMF: IT-Capability Maturity Framework=== <br />
The IT-CMF had its origin in a quality improvement effort at Intel Labs Europe in Ireland. Its intent, as described at the <br />
[https://cio-wiki.org/wiki/IT_Capability_Maturity_Framework_(IT-CMF) CIO Index website] was to quantify and demonstrate the true value impact of IT. IT-CMF is used to measure, develop, and monitor an organization’s EIT capability maturity. It consists of 35 EIT management capabilities organized into four macro capabilities: managing EIT like a business; managing the EIT budget; managing the EIT capability; and managing EIT for business value. Its 35 critical capabilities (CCs) are [http://eitbokwiki.org/Enterprise_IT_Maturity_Assessment described] as “A defined EIT management domain that helps mobilize and deploy EIT-based resources to effect a desired end, often in combination with other resources and capabilities”. <br />
===CMMI: Capability Maturity Model Integration (US)===<br />
The CMMI had its origin in 1987 in a model requested by the U.S. Department of Defense for determining the capability maturity of contractor software development organizations. This became the Capability Maturity Model (CMM). Since then, it has been expanded into a set of Capability Maturity Models, all based on five levels of demonstrably increasing maturity as measured by organization performance. That set was then integrated and became the CMMI. The CMMI set addresses [https://cmmiinstitute.com/dev Development], [https://cmmiinstitute.com/svc Services], [https://cmmiinstitute.com/sm Supplier Management], [https://cmmiinstitute.com/pm People Management], and [https://cmmiinstitute.com/dm Data Management].<br />
===SFIA: Skills Framework for the information Age (Europe, Canada and US)===<br />
The SFIA Framework has been downloaded and used by organizations and individuals in nearly 180 countries. It can be downloaded for free at [https://www.sfia-online.org]. It identifies 97 professional skills across EIT and supporting areas with seven levels of responsibility, which provide generic levels of responsibility, taking into account reflect experience and competency. These describe the behaviors, values, knowledge, and characteristics that an individual should have in order to be considered competent at a particular level.<br />
===E-CF: European Competency Framework (EU)===<br />
The ECF was the first sector-specific implementation of the European Qualifications Framework (EQF). The European Norm (EN) 16234-1 European e-Competence Framework (e-CF) provides a reference of 41 competences as applied at the Information and Communication Technology (ICT) workplace, using a common European reference for competences, skills, knowledge and proficiency levels. The E-CF Explorer web tool is available [https://ecfexplorer.itprofessionalism.org/ online].<br />
===I Competency Dictionary: EIT skills as Defined by METI/ IPA (Japan)===<br />
The Japanese government’s Information-Technology Promotion Agency (IPA), established by the Ministry of Economy, Trade and Industry (METI) developed the ”I Competency Dictionary” (iCD) to support the IT Engineers Examination. It underlies the METI/IPA Skills Standards for IT Professionals, abbreviated as ITSS, established in 2002. ITSS organizes skills within the information services industry into 11 job categories and 35 specialty fields. In each field, there are seven levels of competence based on individual experience and ability to perform. One appealing feature of ITSS is that this standard allows engineers to draw roadmaps for their own futures and career advancement (Career Path). Approximately 90% of large enterprises and over 60% of SMEs in Japan have introduced or are considering using ITSS. Information in English is available at https://www.ipa.go.jp/english/humandev/forth.html.<br />
===ITIL: Information Technology Infrastructure Library===<br />
According to ITLIlibrary.org, the ITIL Open Guide website, “The Information Technology Infrastructure Library (ITIL) defines the organisational structure and skill requirements of an information technology organisation and a set of standard operational management procedures and practices to allow the organisation to manage an IT operation and associated infrastructure. … The [https://www.itlibrary.org/ “library”] itself continues to evolve. This comprises five distinct areas: <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Strategy ITIL Service Strategy]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Design ITIL Service Design]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Transition ITIL Service Transition]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Operation ITIL Service Operation]; and <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Continual_Service_Improvement ITIL Continual Service Improvement].”<br />
It originally grew out of a British government sponsored effort to regularize IT Service Management (ITSM). <br />
==References==<br />
===Works Cited===<br />
Fong, E.N. and A.H. Goldfine. 1989. ''Information Management Directions: The Integration Challenge. '' National Institute of Standards and Technology (NIST) Special Publication 500-167, September 1989. https://csrc.nist.rip/library/NIST%20SP%20500-167.pdf <br />
<br />
Hammer, M., T.H. Davenport and J. Champy. 1986. ''Dispersion and Interconnection: Approaches to Distributed Systems Architecture'', Cambridge, MA: CSC Index Inc. and Hammer and Company, Inc. (June 1986). Available as: https://www.globalaea.org/general/custom.asp?page=Resources <br />
<br />
Hilliard, R. 2015. “Lessons from the fundamental unity of architecting”. ''Software Engineering in the Systems Context'', editors: Ivar Jacobson and Harold 'Bud' Lawson.<br />
<br />
Hofmeister, C. et al. 2007. “A general model of software architecture design derived from five industrial approaches”. ''The Journal of Systems and Software'' 80(1). <br />
<br />
ISO/IEC 25010:2011 ''Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models'', 4.2.3.2.<br />
<br />
ISO/IEC/IEEE 42010 Users Group. ''Survey of Architecture Frameworks'' Available as: http://www.iso-architecture.org/42010/afs/<br />
<br />
ISO/IEC/IEEE. 2011. ISO/IEC/IEEE 42010:2011, ''Systems and software engineering — Architecture description. ''<br />
<br />
PMI. 2013. ''Software Extension to PMBOK® Guide – Fifth Edition. '' Newtown Square, PA, USA: Project Management Institute (PMI). Available as: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/software-extension-5th-edition.<br />
<br />
Rivera, R. 2013. “The PRISM Architecture Framework – Was it the Very First Enterprise Architecture Framework?” ''Journal of Enterprise Architecture'', November 2013<br />
<br />
Zachman, J. 1987. “A Framework for Information Systems Architecture”. ''IBM Systems Journal'', pp454-470, 1987 <br />
<br />
===Primary References===<br />
IEEE Computer Society. ''Enterprise IT Body of Knowledge''. Available: http://eitbokwiki.org<br />
<br />
=-=Additional References===<br />
IT Capability Maturity Framework (IT-CMF): The Body of Knowledge Guide. 2015. Editors. Martin Curley, Jim Kenneally, Marian Carcary. Van Haren Publishing.<br />
<br />
Lessons from Systems Engineering Failures: Determining Why Systems Fail, The State of Systems Engineering Education, and Building an Evidence-Based Network to Help Systems Engineers Identify and Fix Problems on Complex Projects, Diane Constance Aloisio, December 2018.<br />
<br />
===International Standards Guiding EIT===<br />
ANSI/AIAA. 2012. ''ANSI/AIAA Guide to the Preparation of Operational Concept Documents. '' ANSI/AIAA G-043A-2012e.<br />
<br />
IEEE 2012 Std 828™-2012, ''IEEE Standard for Configuration Management in Systems and Software Engineering. ''<br />
<br />
ISO 10004:2012, Quality management—Customer satisfaction—Guidelines for monitoring and measuring<br />
<br />
ISO 10007:2003, Quality management systems—Guidelines for configuration management<br />
<br />
ISO 18238:2015, Space systems—Closed loop problem solving management<br />
<br />
ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models<br />
<br />
ISO/IEC 16350:2015, Information technology—Systems and software engineering—Application management<br />
<br />
ISO/IEC 19770-1:2012, Information technology—Software asset management—Part 1: Processes and tiered assessment of conformance<br />
<br />
ISO/IEC 20000-1:2011, (IEEE Std 20000-1:2013) Information technology—Service management—Part 1: Service management system requirements<br />
<br />
ISO/IEC 20000–2:2012, Information technology—Service management—Part 2: Guidance on the application of service management systems<br />
<br />
ISO/IEC TR 20000–10:2015, Information technology—Service management—Part 10: Concepts and terminology<br />
<br />
ISO/IEC TR 20000–11:2015, Information technology—Service management—Part 11: Guidance on the relationship between ISO/IEC 20000-1:2011 and related frameworks: ITIL®<br />
<br />
ISO/IEC TR 20000-12—Information technology—IT Service management—Part 12: Guidance on the relationship between ISO/IEC 20000-1:2011 and service management frameworks: CMMI-SVC®<br />
<br />
ISO/IEC/IEEE 14764-2006, Software Engineering—Software Lifecycle Processes—Maintenance<br />
<br />
ISO/IEC 15939:2007, Systems and software engineering—Measurement process<br />
<br />
ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description <br />
<br />
<br />
----<br />
<center>[[ Systems Engineering and Economics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Quality Attributes|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Enterprise_IT&diff=66941
Systems Engineering and Enterprise IT
2023-05-07T03:56:48Z
<p>Mhaas: </p>
<hr />
<div>----<br />
'''''Lead Authors:''''' Chuck Walrad and Richard Hilliard<br />
----<br />
This article forms part of the [[Related Disciplines]] knowledge area (KA). It discusses enterprise IT, building upon the concepts and practices of Systems Engineering presented elsewhere in the SEBOK. Systems Engineering is integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of ''engineered technical systems''. <br />
<br />
== Enterprise IT Introduction==<br />
Although it had its origin in the need to improve success rates in U.S. Government outsourcing of technical systems, Systems Engineering is also integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of [https://www.incose.org/about-systems-engineering/system-and-se-definition/systems-engineering-definition#ENGINEERED_SYSTEM engineered technical systems].<br />
Examples of EIT systems include enterprise resource planning, supply chain management and customer relationship management systems, accounting, finance, inventory and order management, marketing, planning, purchasing, and sales.<br />
In the late 1980s and throughout the 1990s, EIT organizations became increasingly aware that the success rates of IT projects were very low, and that their enterprise customers were increasingly unhappy with their EIT investments. The Standish Group sought to understand what was going on. Their findings were presented in the [https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf Chaos Report] (1994):<br />
The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable but could easily be in the trillions of dollars.<br />
As a result, commercial IT organizations, through the auspicious parallel emergence of the Total Quality Management movement and the increasingly widespread development of application development methodologies (ADM) by IT management consulting firms, recognized the need for the principles of Systems Engineering and cross-functional teams (Integrated Product Teams [https://www.sebokwiki.org/wiki/Integrated_Product_Team_(IPT)_(glossary)]. It should be noted that there is considerable overlap today between what constitutes Systems Engineering and what constitutes [[Project and Portfolio Management|Relationships between Systems Engineering and Project Management]] (see [https://www.pmi.org/learning/library/bridging-gap-program-management-systems-engineering-6213 PMI]). This article does not attempt to resolve this issue. Note that the “[[Related Business Activities|following business management activities]] can be ''supported'' by enterprise systems engineering (ESE) activities” [emphasis added]: <br />
* mission and strategic planning,<br />
* business processes and information management,<br />
* performance management,<br />
* portfolio management,<br />
* resource allocation and budgeting, and<br />
* program and project management.<br />
Note that these same areas have been designated as being supported by Project Management Offices. However, since a key difference between project management and systems engineering has been identified as the requirement that the latter includes technical expertise in the product/system of concern, focus should be on systems engineering and integrated product teams (IPTs). <br />
With IPTs, each product is shepherded from concept through delivery and support to retirement by a cross-functional team that includes representatives from each area of responsibility, such as customer requirements development, design and development, test, configuration management, release engineering, delivery, and support.<br />
As enterprises have come to depend more and more on technology to perform effectively, Enterprise IT organizations have matured, often due to the influence of IT consulting firms that make it their business to keep abreast of best practices.<br />
<br />
== EIT Concepts ==<br />
This knowledge area (KA) discusses enterprise IT, building upon the concepts elucidated in the IEEE/ACM ''[http://eitbokwiki.org EITBOK Guide to the Enterprise Information Technology Body of Knowledge]'' and general concepts of Systems Engineering elsewhere in SEBOK. <br />
An enterprise may be viewed from various perspectives: such as a system or a [[system of systems (SoS)|Enterprise Systems Engineering]]:<br />
* system-like enterprise: enterprises, like other systems, may have a tight coupling, single-executive function; <br />
* system of systems-like enterprise: may be a loosely coupled group of organizations with blurred boundaries and (yet) with (some) shared outcomes.<br />
The choice of perspective may vary with many factors: the enterprise itself, the mission or purpose, or the particular engineering task at hand. We can view an enterprise as a system with inputs and outputs in relation to the outside world, or a system of systems interacting through their individual inputs and outputs. <br />
An enterprise usually involves one (or more) organization(s) but need not be identified with the organization. As the scope of human and organizational participants of the enterprise widen, there may be no single point of control. For example, an ''extended enterprise'' could include a company, its suppliers and customers.<br />
Whatever perspective (system-like, SoS-like, other) is taken there are [[key ingredients|Enterprise Systems Engineering Background]] of any enterprise: capabilities, individual (competencies) and the organizational design. [[Capabilities|Enterprise Capability Management]] can be further categorized: “There are three different kinds of capability: organizational capability, system capability, and operational capability.” These capabilities determine what the enterprise is able to produce which may be external offerings or internal mechanisms. Operational capabilities create services and/or products which in turn produce value as determined by stakeholders. The capabilities of an enterprise are realized through [[Enterprise Systems Engineering Background|various enterprise elements]], including: “hardware, software, personnel, facilities, data, materials, techniques, and even services”. which include “soft” items, like people, processes, principles, policies, practices, organizations, doctrine, theories, and beliefs.<br />
EIT capabilities exist through lifecycles spanning from creation through eventual replacement and disposal. ''Life cycle models'' are schemes to aid in the understanding, design, planning and management of the capability of interest. <br />
“A life cycle for a system generally consists of a series of stages regulated by a set of management decisions which confirm that the system is mature enough to leave one stage and enter another.” Basic life cycle terms and concepts are discussed in [[System Lifecycle Approaches]]. Some typical life cycles are discussed in [[System Lifecycle Models]].<br />
A life cycle-based approach can be deployed across the several levels and used to manage evolution. These levels are:<br />
* the enterprise itself,<br />
* the processes and organizations constituting the enterprise,<br />
* the systems enabling the capabilities, services or products provided. <br />
It is important to distinguish between ''product'' and ''project'' lifecycle models. A product’s life cycle extends from its initial concept approval, through development and distribution, to its retirement. This is the cycle that is managed within an Enterprise IT organization, since EIT must manage the hardware or software product from its introduction, in the case of acquired capabilities, or from its concept approval and development, in the case of capabilities it builds, through its deployment, maintenance and eventual retirement (withdrawal). Each of these stages is usually managed as a project or a series of projects.<br />
However, most discussions of life cycles within software and systems discussions focus on ''project'' life cycles. See, for example, the ''Software Extension to PMBOK Guide'' (PMI 2013).<br />
==System of Systems Context in EIT==<br />
“Enterprise IT” (EIT) is used both to refer to the technology organization/business unit within the enterprise and to the enterprise’s information technology systems. In this article, we use EIT to refer to the technology systems. When referring to the organization, we use the phrase “Enterprise IT organization” or EIT organization. <br />
Enterprise IT organizations are responsible for complex socio-technical systems. Socio-technical systems in a business context (thus, EIT) contain technical elements (software, hardware, networks, storage, databases, etc.) but they also contain essential human components and necessary business processes. As covered in [[Introduction to Systems Engineering Fundamentals]], they exist in an engineered System Context that is a set of system component interrelationships within a real-world environment:<br />
This includes where problems come from and how they are defined, how we identify and select candidate solutions, how to balance technology and human elements in the wider solution context, how to manage the complex organizational systems needed to develop new solutions, and how developed solutions are used, sustained and disposed of. … Systems Engineering should consider the full Engineered System Context so that the necessary understanding can be reached and the right systems engineering decisions can be made. <br />
Socio-technical systems also have the following key characteristics: ''Openness'' in that they strongly interact with their environments, and ''unfinished'' in that they evolve over time.<br />
A complex of EIT systems is essential to the successful functioning of the humans in the enterprise. They rely on EIT’s technology for communication, for paying employees, for people management, for business measurement, and often for managing supply chains. Thus, “EIT needs to be viewed as a strategic partner to all the other functions and business units within an enterprise. This means that the results produced by EIT along with its effectiveness and efficiency are all critically important to the success of the enterprise.” [http://eitbokwiki.org/What_is_the_Enterprise_Perspective%3F]<br />
To accomplish this mission, the EIT organization builds and acquires new systems or system components, integrates them into the mega System of Systems, and maintains the integrity and interoperability of the individual components, but also the integrity of the entire complex of systems. In addition, security and performance levels must be achieved, benchmarked and maintained or improved.<br />
==Major concerns of the EIT Organization==<br />
The [http://eitbokwiki.org ''Enterprise IT Body of Knowledge''] provides a good deal of information about these major concerns, which we will not replicate here. Rather, links to the relevant areas are provided. The EITBOK demonstrates how, in providing technology systems and services to the enterprise, the EIT organization must skillfully manage such concerns as the following.<br />
<br />
===Enterprise Architecture===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Enterprise_Architecture Enterprise Architecture] for additional information. ''<br />
[http://eitbokwiki.org/Glossary#ea ''Enterprise architecture''] (EA) is the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. EA applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their organization's strategies. Enterprise architecture builds upon many of the concepts and practices of [[System Architecture Definition|systems architecture]] and also software architecture [https://www.sebokwiki.org/wiki/System_Architecture_Definition].<br />
This section will discuss Enterprise Architecture from the perspective of key [[Principles of Systems Thinking]], designated in this article with '''''bold italics'''''. There are many commonalities in architecture whether one is architecture systems, software or the enterprise [Unity]. In this article we highlight both commonalities and differences between Enterprise Architecture and Systems Architecture. <br />
Architecture takes place at the juncture of design problems and their solutions. Design problems rarely arrive fully formulated or “hatched” for the architect; much of the architecture effort is to analyze or formulate the problems to be solved. Often this involves negotiation both within the enterprise and with outside stakeholders. Possible solutions are limited by resources and schedule and therefore often must also be negotiated.<br />
A dominant principle of Enterprise Architecture is '''''separation of concerns''''' (SoC). This is due to the complexity of enterprises, with many forces acting upon them; the many technologies and disciplines involved in their creation and day-to-day operations; and due to the diversity of stakeholders involved in the enterprise (see [[EIT Roles]]). <br />
An application of SoC is the '''''boundary''''' principle which is crucial to separate what is “inside” the enterprise from what is “outside”. While the former is often under the enterprise’s control, the latter is often beyond its control. <br />
For some systems, determining the boundary is a key decision, subject to many possibilities and consequences. This is perhaps less the case for enterprises whose bounds are determined by the extent of organizations, regulations, supply chains or other criteria. Within an established boundary, the '''''holism''''' principle applies: to treat the enterprise as a unified whole, and, in particular, with respect to the '''''interaction''''' of the enterprise with its ''environment''—including stakeholders, other enterprises and systems. From an enterprise IT perspective, an enterprise is a ''system of systems. '' SoC offers a way to focus on the constituent systems in terms of their interconnections to one another to form the enterprise.<br />
Another useful application of SoC is to apply the principle of '''''multiple views''''' to depict the architecture of the enterprise in different ways to address the diverse interests (i.e., ''concerns'') of an enterprise’s various stakeholders. Each ''architecture view'' presents a specific perspective on the enterprise. To be understandable to its audiences (those various stakeholders), each view should follow the conventions of its ''architecture viewpoint'' (ISO/IEC/IEEE 42010 2011). Just as a map should have a legend, each view should have a documented viewpoint providing a prescribed set of conventions for looking at the enterprise through the resulting view. A viewpoint definition serves as a contract between the architect and stakeholders on ''how'' a selected set of concerns are to be addressed. Each viewpoint allows the architect to consider the enterprise in terms of various kinds of elements and relations among them and to present that view to those “concerned” stakeholders. Dominating concerns in enterprise architecture include interoperability, quality of systems and services, operations, managing change, and alignment with the enterprise’s mission, market, and technology. Via the principle of '''''dualism''''', we recognize that some viewpoints are paired, such as with process/data duality. Another pervasive duality in the enterprise is of people/technology in terms of what capabilities are automated and which are performed by people.<br />
In support of enterprise architecture, there are numerous ''enterprise architecture frameworks'' each providing a pre-defined, integrated set of viewpoints to frame typical, recurring concerns (ISO/IEC/IEEE 42010 Users Group 2022). The earliest recorded framework was (Hammer et al. 1986), developed in the mid-1980s in response to growing availability of distributed computing to the enterprise (Rivera 2013). In the late 1980s, US NIST created its Enterprise Architecture Model as a guide for US federal departments to organize their IT offerings (Fong and Goldfine 1989). NIST’s 5-layer model remains influential today. Despite never using the term “enterprise,” Zachman’s information systems architecture has had a major influence on how subsequent frameworks have been organized and depicted using grids or cubes. Later frameworks have evolved in response to emerging concepts, such as the move from client-server to service-oriented applications, as in the OASIS SOA Reference Model and its associated framework. The 1990s saw a proliferation of frameworks for defense enterprises including US DODAF, UK MODAF, NATO’s NAF and led to successors such as OMG’s UAF.<br />
Yet another application of '''''separation of concerns''''' is distinguishing today’s needs versus facilitating future needs; balancing '''''stability/change''''' and highlighting the temporal planning aspect of architecture of the enterprise. In concert with applying SOC, the architect uses the principle of '''''abstraction''''' to “forget” some details of the subject and thus focus on essentials. Just as SoC is a way of taking things apart, '''''abstraction''''' is a way of unifying or putting like things together through generalization. These two principles are perhaps the most central to architecture. SoC and abstraction work together: SoC picks out subjects and abstraction helps architects to focus upon the essentials of each subject. <br />
Returning to the '''''boundary''''' and '''''holism''''' principles, the enterprise architect applies these recursively. As architecting proceeds, the internal details of the enterprise become known in terms of '''''interaction''''' among its parts and other '''''relations'''''. Again, '''''multiple views''''' are used to factor specific '''''relations'''''into distinct views. Typical relations include Causality, Dependency, Client-Server, and Input-Output. <br />
There are a variety of ways to structure the enterprise based upon stakeholder needs, mission or charter, technologies or capabilities already in place. Among these are structuring principles including: <br />
* '''''Modularity''''' (separate and group capabilities into modules by commonalities); <br />
* '''''Network''''' (modules are linked together); <br />
* '''''Encapsulation''''' (separating architecture modules use from how they are implemented); <br />
* '''''Layer Hierarchy''''' (separation through gradual refinement); <br />
* ''''' Regularity''''' (uniformity of interactions, of structure within layer, within network). <br />
* ''''' Similarity/Difference''''' (recognizing the limits of Regularity)<br />
A simple pattern for architecture has been defined (Hofmeister ''et al. '' 2007). Its elements are Analysis, Synthesis and Evaluation. See Figure 1 below. <br />
''Architecture Analysis'' formulates architecturally-significant requirements (ASRs)—those requirements which influence an enterprise’s architecture. Architecture analysis is based on identified concerns and other information based on understanding the enterprise’s environment, known requirements, stakeholder needs and any constraints. ASRs reflect the “design problems” that the architecture must solve. In many cases, negotiations take place to modify incoming needs, requirements and expectations to make solutions possible. The result of this activity takes the form of ASRs, including architecture principles and initial enterprise-wide decisions.<br />
''Architecture Synthesis'' develops candidate solutions in response to the concerns and ASRs. During Synthesis the architect works out the details of solutions to the identified design problems, tradeoff and interactions between them which are likely to generate further design problems. Synthesis elaborates the ASRs, principles and initial decisions into more detailed solution elements. The principle of ''''' EQUIFINALITY''''' reminds us that for many stable situations (i.e., states of the enterprise), there are many ways to reach those states.<br />
''Architecture Evaluation'' validates whether chosen solutions satisfy ASRs or whether rework is needed (ISO/IEC/IEEE 42030 2019).<br />
Applying the principles discussed above is pervasive in enacting the Analysis–Synthesis–Evaluation pattern iteratively. <br />
<br />
[[File:EIT Figure 1 - Higher Resolution.png|centre|thumb|1000px|'''Figure 1. A pattern for Architecture.''']]<br />
<br />
While there are many commonalities among EIT, systems and software architectures, Figure 2 addresses the relationships ''between'' them. Viewing an enterprise as a system, the EIT architecture governs the fundamental IT decisions of the enterprise. That enterprise might be extended to “outsiders” such as vendors, suppliers and perhaps customers. Depending upon the enterprise, the ''governs'' relationship may entail very strict rules or loose guidance. <br />
Within the enterprise, the ecosystem of systems, applications and data may be viewed as a system of systems. The EIT Architecture constrains the architectures governing individual systems, applications and data stores within the enterprise, so that these are able to interoperate and otherwise “play nicely” together.<br />
<br />
[[File:EIT Figure 2.png|centre|thumb|1000px|'''Figure 2. Relating Enterprise IT, Systems and Software Architecture.''']] <br />
<br />
===Strategy and Governance===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance] for additional information. ''<br />
<blockquote><br />
[http://eitbokwiki.org/Glossary#eit Enterprise information technology] (EIT) governance is the established process of defining the strategy for the EIT organization and overseeing its execution to achieve enterprise goals. Strategic planning translates the larger enterprise’s goals into EIT goals and defines what EIT must do to achieve those goals. This effort then communicates this hierarchy of goals: EIT goals as well as how they support the enterprise’s goals. EIT governance drives needed changes to achieve those goals, while maintaining agreed levels of operation. Taking into account various perspectives (such as financial, historical, environmental, and future projections), a strategic plan is a roadmap for action and change, both vertically and horizontally, across the EIT organization. The EIT organization’s strategic plans are based on the enterprise’s strategic plans, focusing on EIT’s role in them; EIT governance provides a monitoring and control framework to achieve strategic goals and objectives. Thus, EIT governance is essential for achieving the EIT strategy and goals..<br />
-[http://eitbokwiki.org/Strategy_and_Governance EITBOK wiki]<br />
</blockquote><br />
<br />
The principle of ''''' PARSIMONY''''' applies here, too (see [[Principles of Systems Thinking]]). These principles will be designated in this article with '''''bold italics'''''. For example, the simplest possible measurement and reporting systems are most likely to be used and not corrupted. Similarly, the EIT organizational structure should be straightforward and easy to traverse so that staff can communicate and problem-solve in teams.<br />
In governing the EIT organization to meet its dual goals of satisfying its customers and meeting its budget and schedule commitments, EIT management encounters the difficulty of managing in the face of '''''dualism''''', “ensuring a constant dynamic balance often through a cyclic dominance of one element and then the other”. The most obvious instance of handling ''''' dualism''''' in EIT is the trade-off between budget, project prioritization and features within projects.<br />
===Change===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Change_Initiatives Change Initiatives] for more information. ''<br />
There are two levels of change management discussed in the EITBOK: organizational change management and changes to the IT organization’s assets, whether they be software, hardware, or telecommunications systems.<br />
In the larger sense, the introduction of new systems and services often also requires changes in people’s jobs and in the processes used to accomplish those jobs. Such efforts are intended to increase business value. Such changes require change initiatives because they involve guiding a mixture of stakeholders through the change process. This is one aspect of [http://eitbokwiki.org/Change_Initiatives change management].<br />
Change also occurs when existing systems or services must be updated to meet new needs. Depending on the scope of the proposed changes, a change initiative may be required in this situation, too. At any rate, a change request process must be initiated and tracked to disposition (deferral, rejection, or implementation). Changes also come about as a result of defect reports. In such cases, the defect report must be tracked throughout the report’s life cycle, to disposition (deferral, rejection, or implementation).<br />
These latter types of change management are discussed in detail in the EITBOK’s section on [http://eitbokwiki.org/Operations_and_Support Operations and Support].<br />
===Interoperability of Component Systems===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Interoperability interoperability] for more information. ''<br />
As explained in the [http://eitbokwiki.org/Interoperability#One EITBOK], ''interoperability'' means “the ability of systems (including organizations) to exchange and use exchanged information without knowledge of the characteristics or inner workings of the collaborating systems (or organizations).” This definition is based on an ISO definition: “degree to which two or more systems, products, or components can exchange information and use the information that has been exchanged.” (ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models, 4.2.3.2. ) Note that this definition includes hardware components as well as software systems and the organizations in which they are used.<br />
Because technology changes so rapidly, and organizations themselves are frequently changing, achieving and maintaining interoperability is crucial. It is one of the main reasons that providing IT services is difficult and how it differs from engineering and delivering finished products, whether off-the-shelf products or bespoke systems.<br />
===Security of Systems and Data===<br />
<blockquote><br />
There are only two types of companies: those that have been hacked, and those that will be.<br />
-FBI Director Robert Mueller, October 2012<br />
</blockquote><br />
<br />
<blockquote><br />
There are two kinds of big companies in the United States. There are those who've been hacked by the Chinese and those who don't know that they've been hacked by the Chinese<br />
-FBI Director James Comey, October 2014<br />
</blockquote><br />
''See the EITBOK’s section on [http://eitbokwiki.org/Security security] for additional information. ''<br />
While there are many definitions for security, most include the three dimensions of confidentiality, integrity, and availability (sometimes referred to as the [http://eitbokwiki.org/Glossary#ciatriad CIA triad]). As such, the primary goal of EIT security is to preserve the confidentiality, integrity, and availability of information and information systems. <br />
The principles behind an organization’s [http://eitbokwiki.org/Glossary#isms information security management system] (ISMS) should be to design, implement, and maintain a coherent set of policies, processes, and systems that keep the risks associated with its information assets at a tolerable level, and yet, manage the cost and inconvenience of said risk management. As such, the goals of EIT security are to:<br />
* Always understand the current risk tolerance of the enterprise with respect to information and device security.<br />
* Understand the security threats and potential damages to information, devices, and individuals.<br />
* Create and follow policies and procedures that keep cyberattack risk and damages at or below a tolerable level.<br />
* Effectively and efficiently detect and deal with<br />
[http://eitbokwiki.org/Security#One cyberattack incidents].<br />
Ensuring security in EIT has been made even more pressing and more difficult by the proliferation of mobile devices in enterprises and their ever-increasing use to conduct business. Increasingly, personal devices (Bring Your Own Device – BYOD) are used, accessing both corporate networks and public networks. The cost of [https://www.checkpoint.com/downloads/products/check-point-mobile-security-survey-report2013.pdf mobile security incidents] very easily can outweigh the cost of the mobile device itself. <br />
==Quality of Systems and Services==<br />
The Enterprise ''Information'' Technology organization has, since its origins, had as its primary responsibility the timely provision of information to the larger organization. The information is expected to be not only timely, but also accurate and relevant. While the EIT organization itself may not be responsible for creating the data, it is responsible for the physical and logical validity and [https://simplicable.com/new/data-integrity-vs-data-quality integrity of the data] that is used to construct information. It is for this reason that defining and using appropriate processes is essential to ensure high-quality operation, including the development or acquisition, implementation and integration of new or changed capabilities.<br />
The EITBoK details the quality concepts of<br />
* How to approach measuring [http://eitbokwiki.org/Quality#Measuring_Quality Quality]<br />
* The importance of Quality in [http://eitbokwiki.org/Quality#Requirements_Management Requirements Management]<br />
* Understanding an organization’s [http://eitbokwiki.org/Quality#Quality_Capability Quality Capability]<br />
* The differences between [http://eitbokwiki.org/Quality#QMS_and_QC_vs._QA QMS, QC and QA]<br />
* Cost of Quality in [http://eitbokwiki.org/Quality#Technical_Debt_and_the_Cost_of_Rework Technical Debt and the Cost of Rework]<br />
==Disaster Preparedness==<br />
<br />
As explained in the [http://eitbokwiki.org/Disaster_Preparedness EITBOK], disaster preparedness and [http://eitbokwiki.org/Glossary#dr disaster recovery] (DR) support business-continuity planning and include planning for EIT resiliency, as well as recovery from adversity, so that critical business services affected are restored to a satisfactory working state within an [http://eitbokwiki.org/Glossary#acceptable acceptable] timeframe after an event.<br />
The EITBoK devotes a chapter to how the EIT organization and its parent must plan in advance for how it will provide sufficient organizational resilience to recover from disasters and return to normal operation as rapidly as possible.<br />
It provides the following examples of disasters and service interruptions that could occur and should be considered in prevention and recovery planning:<br />
These are examples of disasters:<br />
* Natural disaster affecting datacenters or EIT service operations (flood, fire, earthquake, wind)<br />
* Security breach resulting in a disaster (destruction of data, admin password changes, virus/malware installation, sabotage)<br />
* Usage error (accidental deletion, unplug/turn off system resulting in corruption)<br />
* Utility failure affecting datacenters (loss of power even after UPS)<br />
* Vendor failure (cloud provider security failure, oil spill)<br />
* Staffing issue (employment dispute/walkout, epidemic)<br />
These are examples of unpreparedness:<br />
* Requiring use of computers or printers when power is out<br />
* Requiring use of Internet when power or connectivity is out<br />
* Single point of knowledge/control for administration access<br />
* Lack of offsite backup storage<br />
* Lack of working restoration from backups<br />
* Lack of failover datacenters in separate locations<br />
* Undocumented or out-of-date documentation for system interfaces<br />
*Requiring use of phones that are out of power<br />
* Lack of designation of leaders in restoration efforts (who is in charge of restoring service and they know they are in charge)<br />
* In general, no cohesive, comprehensive EIT service restoration plan<br />
==Operations and Support of Delivered Systems and Services==<br />
[http://eitbokwiki.org/Operations_and_Support Operations and support activities] focus on maintaining an operation normal state in EIT environments, meaning that systems and processes execute according to expectations, with no surprises to users. This desired normal state requires the careful management of EIT assets and services via Operations, as well as of users via Support.<br />
Normal states can be disrupted either by the expected and planned transition of an asset, or by an unexpected event, be it as large as a disaster or by the discovery of a system defect. In the former case, the Disaster Recovery Plan is executed; in the latter, incident management kicks in when a system halts, or problem management is exercised when an operational system is not functioning as expected. The processes needed to ensure effective application of these complex functions is detailed in the [http://eitbokwiki.org/Operations_and_Support#Guiding_Principles Operations and Support Knowledge Area] within the EITBOK. <br />
ISO/IEC/IEEE 20000 may be used by any organization to develop and manage EIT operations, along with the current version of [https://www.servicenow.com ITIL].<br />
ITIL for many is the tool of choice for the operations and infrastructure side of IT, particularly for IT services. <br />
==Ethics==<br />
See the EITBOK’s section on [http://eitbokwiki.org/Ethics ethics] for additional information.<br />
Both the IEEE and ACM require their members to adhere to Codes of Ethics. See the [https://www.ieee.org/about/corporate/governance/p7-8.html IEEE Code of Ethics] and [https://www.acm.org/code-of-ethics ACM Code of Ethics and Professional Conduct]. Both of these can be downloaded freely. In addition, the IEEE Computer Society and the ACM worked together on the [https://dl.acm.org/action/downloadSupplement?doi=10.1145%2F265684.265699&file=acm-se-code-of-ethics.html Software Engineering Code of Ethics] (also available [https://dl.acm.org/doi/10.1145/265684.265699 here]).<br />
The organization should create an easily accessible Code of Ethics:<br />
* Ethical assertions should be documented and socialized in EIT in the form of a Code of Ethics, tied to the overall business code of ethics, and signed off by all staff so that violations can be cause for reprimand or dismissal.<br />
* Vendors should be held to similar ethical standards.<br />
* Lists of employees who have signed off on the Code of Ethics are maintained by EIT governance.<br />
The EITBOK has identified EIT ethical topics that include:<br />
* Those actions and decisions that may be illegal<br />
* Consideration of the social impact of the work at hand—if it will cause harm<br />
* Alignment of business and EIT strategies and policies to an ethical standard<br />
* Incorporation of the ideals of professionalism<br />
* Adherence to applicable regulatory intent<br />
* Protection for whistle blowers<br />
Areas to specifically highlight:<br />
* Activities that interfere with or corrupt the proper function of computers, applications and systems<br />
* Activities that interfere with digital privacy or intellectual rights of others<br />
* Respect for confidentiality, privacy, permissions, and access rights<br />
* Inappropriate bias (skewing) of analysis and reporting<br />
* Inaction in the face of likely ethics violations<br />
==EIT Roles==<br />
Several roles play a part in accomplishing the EIT organization’s mission. Just as a systems engineer can play several roles in a given project, so might several people in an EIT project combine to fulfill the systems engineering function. <br />
The function of EIT systems engineering is to orchestrate systems development, delivery and operation such that the larger organization achieves favorable outcomes in complex environments. Unlike systems projects that are built for known problems, EIT systems may change in unpredictable ways. A primary concern focuses on how quickly systems adapt to change. This entails a type of resiliency based on skills in establishing options and alternative solutions as well as strategies tailored to the volatility of changing needs and available technologies. It also requires expertise in assuring that systems quality is assured from the start.<br />
Different countries, geographic areas and organizations do not always use the same terminology to reference the functions that the roles contributing to systems engineering perform. The following section will provide information about some major international models for defining EIT skills and capabilities. Generally, though, the necessary roles across the product life cycle include these:<br />
* Business Sponsor/Champion<br />
* Enterprise Architect<br />
* Systems Engineer<br />
* Financial Manager<br />
* Application Architect<br />
* Business Analyst and/or Process Analyst<br />
* Data Analyst and/or Data Architect<br />
* Software Engineer and/or Programmer<br />
* Quality Assurance & Testing<br />
* Network Engineer<br />
* Telecoms Engineer<br />
* Integration Expert <br />
* Transition to Operations Manager<br />
* Release Manager<br />
* Availability Manager<br />
* Capacity Manager<br />
* Change Manager<br />
* Configuration Manager<br />
* EIT Operations Manager<br />
* Incident Management<br />
* Problem Manager<br />
* Service Level Manager<br />
* Database Administrator<br />
* Network Manager<br />
* Product Manager<br />
System engineering activities orchestrate the work of these roles so that they function together, rather than in silos or at cross purposes.<br />
==Examples of Systems Engineering in EIT==<br />
Systems Engineering provides a holistic discipline for integrating and managing the contributions of all roles needed to establish and provide EIT products and services. It ensures that a single perspective does not dominate outcomes; instead, it seeks balance among the many disciplines represented above in creating a consistent product or service that meets the interests and needs of enterprise users (and, perhaps, partners). It boils down to common sense, technical sense, knowing when to ask the right questions, and getting the data to support the answers to those questions. System Engineering achieves this via Systems Engineers. In many instances, though, the SE function is accomplished through Project Management approaches using Integrated Product Teams that include technical experts. Thus, although not specifically calling out a Systems Engineering function, the use of IPTs involved the use of SE practices.<br />
A doctoral dissertation from Purdue University performed a survey and causal analysis of project failures and of accidents(Aloisio, 2018). The results were similar to those found in reviews of IBM consulting projects in the 1990s . The following are examples of Systems Engineering interventions that prevented project failures. Almost all point to the lack of the System Engineering balancing act needed for product delivery.<br />
* A widely used document processing product was undergoing a major upgrade. The new VP of Engineering wanted a project review before committing to a schedule. The review showed that the proposed schedule only considered the development effort and did not give sufficient weight to the voices of the testing and documentation organizations, while the needs of the tech support group had been completely overlooked. By establishing an integrated product management team that included technical expertise, as well as expertise in work breakdown and estimating, a realistic effort was defined and the resulting 9-month schedule was met within 3 weeks.<br />
* A Silicon Valley start-up was depending entirely on an offshore development effort to produce its first product. All senior management was in the U.S. The VP of engineering made monthly visits to the development team. The CEO began to feel uneasy about the team’s ability to deliver on schedule sensing that a lot of finger pointing within the development team itself signaled problems. There was no SE or IPT guiding the project. The VP of Engineering seemed unable to sort things out. A project review showed that the probable delivery date was at least 6 months beyond what the CEO was being told. The project was shut down.<br />
* A major player in Human Resource Management had made commitments to deliver a new product. The project involved more than 100 people across the U.S. The delivery date kept slipping. Project roll-out would involve both installation of software and hardware at client sites, as well as installation and staff training at the large, centrally located Client Services organization. Executive Management needed to decide whether to reorganize this very expensive effort or cancel it. Again, the successful solution depended on establishing an effective cross-functional team (IPT) that necessarily included representatives from the technical teams. The IPT was supported by a newly established Project Management Office (PMO). The PMO integrated the geographically disparate efforts by establishing communication channels, as well as common estimating and scheduling practices. The PMO also instituted monthly critical metrics reports to show the IPT bottlenecks and inefficiencies across the project, from development efforts to Client Services set-up to Payroll technical support.<br />
There are far more examples of the lack of systems engineering practices in EIT projects than in their successful use (unfortunately, this seems also to be true in lots of software projects outside of EIT). Systems Engineering provides a holistic discipline for integrating and managing the contributions of all of the roles needed to provide EIT products and services. It ensures that a single perspective does not dominate outcomes.<br />
==Key External Models of EIT Organizational Capability and Maturity==<br />
Because EIT is critical to businesses globally, considerable effort has gone into establishing universal frameworks for EIT skills, along with definitions of levels of capability of each skill. In addition, at least 2 models have been developed for evaluating the organizational performance of EIT. The effectiveness of systems engineering is key to the effectiveness of the EIT organization.<br />
===IT-CMF: IT-Capability Maturity Framework=== <br />
The IT-CMF had its origin in a quality improvement effort at Intel Labs Europe in Ireland. Its intent, as described at the <br />
[https://cio-wiki.org/wiki/IT_Capability_Maturity_Framework_(IT-CMF) CIO Index website] was to quantify and demonstrate the true value impact of IT. IT-CMF is used to measure, develop, and monitor an organization’s EIT capability maturity. It consists of 35 EIT management capabilities organized into four macro capabilities: managing EIT like a business; managing the EIT budget; managing the EIT capability; and managing EIT for business value. Its 35 critical capabilities (CCs) are [http://eitbokwiki.org/Enterprise_IT_Maturity_Assessment described] as “A defined EIT management domain that helps mobilize and deploy EIT-based resources to effect a desired end, often in combination with other resources and capabilities”. <br />
===CMMI: Capability Maturity Model Integration (US)===<br />
The CMMI had its origin in 1987 in a model requested by the U.S. Department of Defense for determining the capability maturity of contractor software development organizations. This became the Capability Maturity Model (CMM). Since then, it has been expanded into a set of Capability Maturity Models, all based on five levels of demonstrably increasing maturity as measured by organization performance. That set was then integrated and became the CMMI. The CMMI set addresses [https://cmmiinstitute.com/dev Development], [https://cmmiinstitute.com/svc Services], [https://cmmiinstitute.com/sm Supplier Management], [https://cmmiinstitute.com/pm People Management], and [https://cmmiinstitute.com/dm Data Management].<br />
===SFIA: Skills Framework for the information Age (Europe, Canada and US)===<br />
The SFIA Framework has been downloaded and used by organizations and individuals in nearly 180 countries. It can be downloaded for free at [https://www.sfia-online.org]. It identifies 97 professional skills across EIT and supporting areas with seven levels of responsibility, which provide generic levels of responsibility, taking into account reflect experience and competency. These describe the behaviors, values, knowledge, and characteristics that an individual should have in order to be considered competent at a particular level.<br />
===E-CF: European Competency Framework (EU)===<br />
The ECF was the first sector-specific implementation of the European Qualifications Framework (EQF). The European Norm (EN) 16234-1 European e-Competence Framework (e-CF) provides a reference of 41 competences as applied at the Information and Communication Technology (ICT) workplace, using a common European reference for competences, skills, knowledge and proficiency levels. The E-CF Explorer web tool is available [https://ecfexplorer.itprofessionalism.org/ online].<br />
===I Competency Dictionary: EIT skills as Defined by METI/ IPA (Japan)===<br />
The Japanese government’s Information-Technology Promotion Agency (IPA), established by the Ministry of Economy, Trade and Industry (METI) developed the ”I Competency Dictionary” (iCD) to support the IT Engineers Examination. It underlies the METI/IPA Skills Standards for IT Professionals, abbreviated as ITSS, established in 2002. ITSS organizes skills within the information services industry into 11 job categories and 35 specialty fields. In each field, there are seven levels of competence based on individual experience and ability to perform. One appealing feature of ITSS is that this standard allows engineers to draw roadmaps for their own futures and career advancement (Career Path). Approximately 90% of large enterprises and over 60% of SMEs in Japan have introduced or are considering using ITSS. Information in English is available at https://www.ipa.go.jp/english/humandev/forth.html.<br />
===ITIL: Information Technology Infrastructure Library===<br />
According to ITLIlibrary.org, the ITIL Open Guide website, “The Information Technology Infrastructure Library (ITIL) defines the organisational structure and skill requirements of an information technology organisation and a set of standard operational management procedures and practices to allow the organisation to manage an IT operation and associated infrastructure. … The [https://www.itlibrary.org/ “library”] itself continues to evolve. This comprises five distinct areas: <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Strategy ITIL Service Strategy]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Design ITIL Service Design]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Transition ITIL Service Transition]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Operation ITIL Service Operation]; and <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Continual_Service_Improvement ITIL Continual Service Improvement].”<br />
It originally grew out of a British government sponsored effort to regularize IT Service Management (ITSM). <br />
==References==<br />
===Works Cited===<br />
Fong, E.N. and A.H. Goldfine. 1989. ''Information Management Directions: The Integration Challenge. '' National Institute of Standards and Technology (NIST) Special Publication 500-167, September 1989. https://csrc.nist.rip/library/NIST%20SP%20500-167.pdf <br />
<br />
Hammer, M., T.H. Davenport and J. Champy. 1986. ''Dispersion and Interconnection: Approaches to Distributed Systems Architecture'', Cambridge, MA: CSC Index Inc. and Hammer and Company, Inc. (June 1986). Available as: https://www.globalaea.org/general/custom.asp?page=Resources <br />
<br />
Hilliard, R. 2015. “Lessons from the fundamental unity of architecting”. ''Software Engineering in the Systems Context'', editors: Ivar Jacobson and Harold 'Bud' Lawson.<br />
<br />
Hofmeister, C. et al. 2007. “A general model of software architecture design derived from five industrial approaches”. ''The Journal of Systems and Software'' 80(1). <br />
<br />
ISO/IEC 25010:2011 ''Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models'', 4.2.3.2.<br />
<br />
ISO/IEC/IEEE 42010 Users Group. ''Survey of Architecture Frameworks'' Available as: http://www.iso-architecture.org/42010/afs/<br />
<br />
ISO/IEC/IEEE. 2011. ISO/IEC/IEEE 42010:2011, ''Systems and software engineering — Architecture description. ''<br />
<br />
PMI. 2013. ''Software Extension to PMBOK® Guide – Fifth Edition. '' Newtown Square, PA, USA: Project Management Institute (PMI). Available as: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/software-extension-5th-edition.<br />
<br />
Rivera, R. 2013. “The PRISM Architecture Framework – Was it the Very First Enterprise Architecture Framework?” ''Journal of Enterprise Architecture'', November 2013<br />
<br />
Zachman, J. 1987. “A Framework for Information Systems Architecture”. ''IBM Systems Journal'', pp454-470, 1987 <br />
<br />
===Primary References===<br />
IEEE Computer Society. ''Enterprise IT Body of Knowledge''. Available: http://eitbokwiki.org<br />
<br />
=-=Additional References===<br />
IT Capability Maturity Framework (IT-CMF): The Body of Knowledge Guide. 2015. Editors. Martin Curley, Jim Kenneally, Marian Carcary. Van Haren Publishing.<br />
<br />
Lessons from Systems Engineering Failures: Determining Why Systems Fail, The State of Systems Engineering Education, and Building an Evidence-Based Network to Help Systems Engineers Identify and Fix Problems on Complex Projects, Diane Constance Aloisio, December 2018.<br />
<br />
===International Standards Guiding EIT===<br />
ANSI/AIAA. 2012. ''ANSI/AIAA Guide to the Preparation of Operational Concept Documents. '' ANSI/AIAA G-043A-2012e.<br />
<br />
IEEE 2012 Std 828™-2012, ''IEEE Standard for Configuration Management in Systems and Software Engineering. ''<br />
<br />
ISO 10004:2012, Quality management—Customer satisfaction—Guidelines for monitoring and measuring<br />
<br />
ISO 10007:2003, Quality management systems—Guidelines for configuration management<br />
<br />
ISO 18238:2015, Space systems—Closed loop problem solving management<br />
<br />
ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models<br />
<br />
ISO/IEC 16350:2015, Information technology—Systems and software engineering—Application management<br />
<br />
ISO/IEC 19770-1:2012, Information technology—Software asset management—Part 1: Processes and tiered assessment of conformance<br />
<br />
ISO/IEC 20000-1:2011, (IEEE Std 20000-1:2013) Information technology—Service management—Part 1: Service management system requirements<br />
<br />
ISO/IEC 20000–2:2012, Information technology—Service management—Part 2: Guidance on the application of service management systems<br />
<br />
ISO/IEC TR 20000–10:2015, Information technology—Service management—Part 10: Concepts and terminology<br />
<br />
ISO/IEC TR 20000–11:2015, Information technology—Service management—Part 11: Guidance on the relationship between ISO/IEC 20000-1:2011 and related frameworks: ITIL®<br />
<br />
ISO/IEC TR 20000-12—Information technology—IT Service management—Part 12: Guidance on the relationship between ISO/IEC 20000-1:2011 and service management frameworks: CMMI-SVC®<br />
<br />
ISO/IEC/IEEE 14764-2006, Software Engineering—Software Lifecycle Processes—Maintenance<br />
<br />
ISO/IEC 15939:2007, Systems and software engineering—Measurement process<br />
<br />
ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description <br />
<br />
<br />
----<br />
<center>[[ Systems Engineering and Economics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Quality Attributes|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Enterprise_IT&diff=66940
Systems Engineering and Enterprise IT
2023-05-07T03:56:20Z
<p>Mhaas: </p>
<hr />
<div>----<br />
'''''Lead Authors:''''' Chuck Walrad and Richard Hilliard<br />
----<br />
This article forms part of the [[Related Disciplines]] knowledge area (KA). It discusses enterprise IT, building upon the concepts and practices of Systems Engineering presented elsewhere in the SEBOK. Systems Engineering is integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of ''engineered technical systems''. <br />
<br />
== Enterprise IT Introduction==<br />
Although it had its origin in the need to improve success rates in U.S. Government outsourcing of technical systems, Systems Engineering is also integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of [https://www.incose.org/about-systems-engineering/system-and-se-definition/systems-engineering-definition#ENGINEERED_SYSTEM engineered technical systems].<br />
Examples of EIT systems include enterprise resource planning, supply chain management and customer relationship management systems, accounting, finance, inventory and order management, marketing, planning, purchasing, and sales.<br />
In the late 1980s and throughout the 1990s, EIT organizations became increasingly aware that the success rates of IT projects were very low, and that their enterprise customers were increasingly unhappy with their EIT investments. The Standish Group sought to understand what was going on. Their findings were presented in the [https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf Chaos Report] (1994):<br />
The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable but could easily be in the trillions of dollars.<br />
As a result, commercial IT organizations, through the auspicious parallel emergence of the Total Quality Management movement and the increasingly widespread development of application development methodologies (ADM) by IT management consulting firms, recognized the need for the principles of Systems Engineering and cross-functional teams (Integrated Product Teams [https://www.sebokwiki.org/wiki/Integrated_Product_Team_(IPT)_(glossary)]. It should be noted that there is considerable overlap today between what constitutes Systems Engineering and what constitutes [[Project and Portfolio Management|Relationships between Systems Engineering and Project Management]] (see [https://www.pmi.org/learning/library/bridging-gap-program-management-systems-engineering-6213 PMI]). This article does not attempt to resolve this issue. Note that the “[[Related Business Activities|following business management activities]] can be ''supported'' by enterprise systems engineering (ESE) activities” [emphasis added]: <br />
* mission and strategic planning,<br />
* business processes and information management,<br />
* performance management,<br />
* portfolio management,<br />
* resource allocation and budgeting, and<br />
* program and project management.<br />
Note that these same areas have been designated as being supported by Project Management Offices. However, since a key difference between project management and systems engineering has been identified as the requirement that the latter includes technical expertise in the product/system of concern, focus should be on systems engineering and integrated product teams (IPTs). <br />
With IPTs, each product is shepherded from concept through delivery and support to retirement by a cross-functional team that includes representatives from each area of responsibility, such as customer requirements development, design and development, test, configuration management, release engineering, delivery, and support.<br />
As enterprises have come to depend more and more on technology to perform effectively, Enterprise IT organizations have matured, often due to the influence of IT consulting firms that make it their business to keep abreast of best practices.<br />
<br />
== EIT Concepts ==<br />
This knowledge area (KA) discusses enterprise IT, building upon the concepts elucidated in the IEEE/ACM ''[http://eitbokwiki.org EITBOK Guide to the Enterprise Information Technology Body of Knowledge]'' and general concepts of Systems Engineering elsewhere in SEBOK. <br />
An enterprise may be viewed from various perspectives: such as a system or a [[system of systems (SoS)|Enterprise Systems Engineering]]:<br />
* system-like enterprise: enterprises, like other systems, may have a tight coupling, single-executive function; <br />
* system of systems-like enterprise: may be a loosely coupled group of organizations with blurred boundaries and (yet) with (some) shared outcomes.<br />
The choice of perspective may vary with many factors: the enterprise itself, the mission or purpose, or the particular engineering task at hand. We can view an enterprise as a system with inputs and outputs in relation to the outside world, or a system of systems interacting through their individual inputs and outputs. <br />
An enterprise usually involves one (or more) organization(s) but need not be identified with the organization. As the scope of human and organizational participants of the enterprise widen, there may be no single point of control. For example, an ''extended enterprise'' could include a company, its suppliers and customers.<br />
Whatever perspective (system-like, SoS-like, other) is taken there are [[key ingredients|Enterprise Systems Engineering Background]] of any enterprise: capabilities, individual (competencies) and the organizational design. [[Capabilities|Enterprise Capability Management]] can be further categorized: “There are three different kinds of capability: organizational capability, system capability, and operational capability.” These capabilities determine what the enterprise is able to produce which may be external offerings or internal mechanisms. Operational capabilities create services and/or products which in turn produce value as determined by stakeholders. The capabilities of an enterprise are realized through [[Enterprise Systems Engineering Background|various enterprise elements]], including: “hardware, software, personnel, facilities, data, materials, techniques, and even services”. which include “soft” items, like people, processes, principles, policies, practices, organizations, doctrine, theories, and beliefs.<br />
EIT capabilities exist through lifecycles spanning from creation through eventual replacement and disposal. ''Life cycle models'' are schemes to aid in the understanding, design, planning and management of the capability of interest. <br />
“A life cycle for a system generally consists of a series of stages regulated by a set of management decisions which confirm that the system is mature enough to leave one stage and enter another.” Basic life cycle terms and concepts are discussed in [[System Lifecycle Approaches]]. Some typical life cycles are discussed in [[System Lifecycle Models]].<br />
A life cycle-based approach can be deployed across the several levels and used to manage evolution. These levels are:<br />
* the enterprise itself,<br />
* the processes and organizations constituting the enterprise,<br />
* the systems enabling the capabilities, services or products provided. <br />
It is important to distinguish between ''product'' and ''project'' lifecycle models. A product’s life cycle extends from its initial concept approval, through development and distribution, to its retirement. This is the cycle that is managed within an Enterprise IT organization, since EIT must manage the hardware or software product from its introduction, in the case of acquired capabilities, or from its concept approval and development, in the case of capabilities it builds, through its deployment, maintenance and eventual retirement (withdrawal). Each of these stages is usually managed as a project or a series of projects.<br />
However, most discussions of life cycles within software and systems discussions focus on ''project'' life cycles. See, for example, the ''Software Extension to PMBOK Guide'' (PMI 2013).<br />
==System of Systems Context in EIT==<br />
“Enterprise IT” (EIT) is used both to refer to the technology organization/business unit within the enterprise and to the enterprise’s information technology systems. In this article, we use EIT to refer to the technology systems. When referring to the organization, we use the phrase “Enterprise IT organization” or EIT organization. <br />
Enterprise IT organizations are responsible for complex socio-technical systems. Socio-technical systems in a business context (thus, EIT) contain technical elements (software, hardware, networks, storage, databases, etc.) but they also contain essential human components and necessary business processes. As covered in [[Introduction to Systems Engineering Fundamentals]], they exist in an engineered System Context that is a set of system component interrelationships within a real-world environment:<br />
This includes where problems come from and how they are defined, how we identify and select candidate solutions, how to balance technology and human elements in the wider solution context, how to manage the complex organizational systems needed to develop new solutions, and how developed solutions are used, sustained and disposed of. … Systems Engineering should consider the full Engineered System Context so that the necessary understanding can be reached and the right systems engineering decisions can be made. <br />
Socio-technical systems also have the following key characteristics: ''Openness'' in that they strongly interact with their environments, and ''unfinished'' in that they evolve over time.<br />
A complex of EIT systems is essential to the successful functioning of the humans in the enterprise. They rely on EIT’s technology for communication, for paying employees, for people management, for business measurement, and often for managing supply chains. Thus, “EIT needs to be viewed as a strategic partner to all the other functions and business units within an enterprise. This means that the results produced by EIT along with its effectiveness and efficiency are all critically important to the success of the enterprise.” [http://eitbokwiki.org/What_is_the_Enterprise_Perspective%3F]<br />
To accomplish this mission, the EIT organization builds and acquires new systems or system components, integrates them into the mega System of Systems, and maintains the integrity and interoperability of the individual components, but also the integrity of the entire complex of systems. In addition, security and performance levels must be achieved, benchmarked and maintained or improved.<br />
==Major concerns of the EIT Organization==<br />
The [http://eitbokwiki.org ''Enterprise IT Body of Knowledge''] provides a good deal of information about these major concerns, which we will not replicate here. Rather, links to the relevant areas are provided. The EITBOK demonstrates how, in providing technology systems and services to the enterprise, the EIT organization must skillfully manage such concerns as the following.<br />
<br />
===Enterprise Architecture===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Enterprise_Architecture Enterprise Architecture] for additional information. ''<br />
[http://eitbokwiki.org/Glossary#ea ''Enterprise architecture''] (EA) is the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. EA applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their organization's strategies. Enterprise architecture builds upon many of the concepts and practices of [[System Architecture Definition|systems architecture]] and also software architecture [https://www.sebokwiki.org/wiki/System_Architecture_Definition].<br />
This section will discuss Enterprise Architecture from the perspective of key [[Principles of Systems Thinking]], designated in this article with '''''bold italics'''''. There are many commonalities in architecture whether one is architecture systems, software or the enterprise [Unity]. In this article we highlight both commonalities and differences between Enterprise Architecture and Systems Architecture. <br />
Architecture takes place at the juncture of design problems and their solutions. Design problems rarely arrive fully formulated or “hatched” for the architect; much of the architecture effort is to analyze or formulate the problems to be solved. Often this involves negotiation both within the enterprise and with outside stakeholders. Possible solutions are limited by resources and schedule and therefore often must also be negotiated.<br />
A dominant principle of Enterprise Architecture is '''''separation of concerns''''' (SoC). This is due to the complexity of enterprises, with many forces acting upon them; the many technologies and disciplines involved in their creation and day-to-day operations; and due to the diversity of stakeholders involved in the enterprise (see [[EIT Roles]]). <br />
An application of SoC is the '''''boundary''''' principle which is crucial to separate what is “inside” the enterprise from what is “outside”. While the former is often under the enterprise’s control, the latter is often beyond its control. <br />
For some systems, determining the boundary is a key decision, subject to many possibilities and consequences. This is perhaps less the case for enterprises whose bounds are determined by the extent of organizations, regulations, supply chains or other criteria. Within an established boundary, the '''''holism''''' principle applies: to treat the enterprise as a unified whole, and, in particular, with respect to the '''''interaction''''' of the enterprise with its ''environment''—including stakeholders, other enterprises and systems. From an enterprise IT perspective, an enterprise is a ''system of systems. '' SoC offers a way to focus on the constituent systems in terms of their interconnections to one another to form the enterprise.<br />
Another useful application of SoC is to apply the principle of '''''multiple views''''' to depict the architecture of the enterprise in different ways to address the diverse interests (i.e., ''concerns'') of an enterprise’s various stakeholders. Each ''architecture view'' presents a specific perspective on the enterprise. To be understandable to its audiences (those various stakeholders), each view should follow the conventions of its ''architecture viewpoint'' (ISO/IEC/IEEE 42010 2011). Just as a map should have a legend, each view should have a documented viewpoint providing a prescribed set of conventions for looking at the enterprise through the resulting view. A viewpoint definition serves as a contract between the architect and stakeholders on ''how'' a selected set of concerns are to be addressed. Each viewpoint allows the architect to consider the enterprise in terms of various kinds of elements and relations among them and to present that view to those “concerned” stakeholders. Dominating concerns in enterprise architecture include interoperability, quality of systems and services, operations, managing change, and alignment with the enterprise’s mission, market, and technology. Via the principle of '''''dualism''''', we recognize that some viewpoints are paired, such as with process/data duality. Another pervasive duality in the enterprise is of people/technology in terms of what capabilities are automated and which are performed by people.<br />
In support of enterprise architecture, there are numerous ''enterprise architecture frameworks'' each providing a pre-defined, integrated set of viewpoints to frame typical, recurring concerns (ISO/IEC/IEEE 42010 Users Group 2022). The earliest recorded framework was (Hammer et al. 1986), developed in the mid-1980s in response to growing availability of distributed computing to the enterprise (Rivera 2013). In the late 1980s, US NIST created its Enterprise Architecture Model as a guide for US federal departments to organize their IT offerings (Fong and Goldfine 1989). NIST’s 5-layer model remains influential today. Despite never using the term “enterprise,” Zachman’s information systems architecture has had a major influence on how subsequent frameworks have been organized and depicted using grids or cubes. Later frameworks have evolved in response to emerging concepts, such as the move from client-server to service-oriented applications, as in the OASIS SOA Reference Model and its associated framework. The 1990s saw a proliferation of frameworks for defense enterprises including US DODAF, UK MODAF, NATO’s NAF and led to successors such as OMG’s UAF.<br />
Yet another application of '''''separation of concerns''''' is distinguishing today’s needs versus facilitating future needs; balancing '''''stability/change''''' and highlighting the temporal planning aspect of architecture of the enterprise. In concert with applying SOC, the architect uses the principle of '''''abstraction''''' to “forget” some details of the subject and thus focus on essentials. Just as SoC is a way of taking things apart, '''''abstraction''''' is a way of unifying or putting like things together through generalization. These two principles are perhaps the most central to architecture. SoC and abstraction work together: SoC picks out subjects and abstraction helps architects to focus upon the essentials of each subject. <br />
Returning to the '''''boundary''''' and '''''holism''''' principles, the enterprise architect applies these recursively. As architecting proceeds, the internal details of the enterprise become known in terms of '''''interaction''''' among its parts and other '''''relations'''''. Again, '''''multiple views''''' are used to factor specific '''''relations'''''into distinct views. Typical relations include Causality, Dependency, Client-Server, and Input-Output. <br />
There are a variety of ways to structure the enterprise based upon stakeholder needs, mission or charter, technologies or capabilities already in place. Among these are structuring principles including: <br />
* '''''Modularity''''' (separate and group capabilities into modules by commonalities); <br />
* '''''Network''''' (modules are linked together); <br />
* '''''Encapsulation''''' (separating architecture modules use from how they are implemented); <br />
* '''''Layer Hierarchy''''' (separation through gradual refinement); <br />
* ''''' Regularity''''' (uniformity of interactions, of structure within layer, within network). <br />
* ''''' Similarity/Difference''''' (recognizing the limits of Regularity)<br />
A simple pattern for architecture has been defined (Hofmeister ''et al. '' 2007). Its elements are Analysis, Synthesis and Evaluation. See Figure 1 below. <br />
''Architecture Analysis'' formulates architecturally-significant requirements (ASRs)—those requirements which influence an enterprise’s architecture. Architecture analysis is based on identified concerns and other information based on understanding the enterprise’s environment, known requirements, stakeholder needs and any constraints. ASRs reflect the “design problems” that the architecture must solve. In many cases, negotiations take place to modify incoming needs, requirements and expectations to make solutions possible. The result of this activity takes the form of ASRs, including architecture principles and initial enterprise-wide decisions.<br />
''Architecture Synthesis'' develops candidate solutions in response to the concerns and ASRs. During Synthesis the architect works out the details of solutions to the identified design problems, tradeoff and interactions between them which are likely to generate further design problems. Synthesis elaborates the ASRs, principles and initial decisions into more detailed solution elements. The principle of ''''' EQUIFINALITY''''' reminds us that for many stable situations (i.e., states of the enterprise), there are many ways to reach those states.<br />
''Architecture Evaluation'' validates whether chosen solutions satisfy ASRs or whether rework is needed (ISO/IEC/IEEE 42030 2019).<br />
Applying the principles discussed above is pervasive in enacting the Analysis–Synthesis–Evaluation pattern iteratively. <br />
<br />
[[File:EIT Figure 1 - Higher Resolution.png|centre|thumb|1000px|'''Figure 1. A pattern for Architecture.''']]<br />
[[File:SEBoK EIT Figure 1.png|centre|thumb|2000px|'''Figure 1. A pattern for Architecture.''']] <br />
<br />
While there are many commonalities among EIT, systems and software architectures, Figure 2 addresses the relationships ''between'' them. Viewing an enterprise as a system, the EIT architecture governs the fundamental IT decisions of the enterprise. That enterprise might be extended to “outsiders” such as vendors, suppliers and perhaps customers. Depending upon the enterprise, the ''governs'' relationship may entail very strict rules or loose guidance. <br />
Within the enterprise, the ecosystem of systems, applications and data may be viewed as a system of systems. The EIT Architecture constrains the architectures governing individual systems, applications and data stores within the enterprise, so that these are able to interoperate and otherwise “play nicely” together.<br />
<br />
[[File:EIT Figure 2.png|centre|thumb|1000px|'''Figure 2. Relating Enterprise IT, Systems and Software Architecture.''']] <br />
<br />
===Strategy and Governance===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance] for additional information. ''<br />
<blockquote><br />
[http://eitbokwiki.org/Glossary#eit Enterprise information technology] (EIT) governance is the established process of defining the strategy for the EIT organization and overseeing its execution to achieve enterprise goals. Strategic planning translates the larger enterprise’s goals into EIT goals and defines what EIT must do to achieve those goals. This effort then communicates this hierarchy of goals: EIT goals as well as how they support the enterprise’s goals. EIT governance drives needed changes to achieve those goals, while maintaining agreed levels of operation. Taking into account various perspectives (such as financial, historical, environmental, and future projections), a strategic plan is a roadmap for action and change, both vertically and horizontally, across the EIT organization. The EIT organization’s strategic plans are based on the enterprise’s strategic plans, focusing on EIT’s role in them; EIT governance provides a monitoring and control framework to achieve strategic goals and objectives. Thus, EIT governance is essential for achieving the EIT strategy and goals..<br />
-[http://eitbokwiki.org/Strategy_and_Governance EITBOK wiki]<br />
</blockquote><br />
<br />
The principle of ''''' PARSIMONY''''' applies here, too (see [[Principles of Systems Thinking]]). These principles will be designated in this article with '''''bold italics'''''. For example, the simplest possible measurement and reporting systems are most likely to be used and not corrupted. Similarly, the EIT organizational structure should be straightforward and easy to traverse so that staff can communicate and problem-solve in teams.<br />
In governing the EIT organization to meet its dual goals of satisfying its customers and meeting its budget and schedule commitments, EIT management encounters the difficulty of managing in the face of '''''dualism''''', “ensuring a constant dynamic balance often through a cyclic dominance of one element and then the other”. The most obvious instance of handling ''''' dualism''''' in EIT is the trade-off between budget, project prioritization and features within projects.<br />
===Change===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Change_Initiatives Change Initiatives] for more information. ''<br />
There are two levels of change management discussed in the EITBOK: organizational change management and changes to the IT organization’s assets, whether they be software, hardware, or telecommunications systems.<br />
In the larger sense, the introduction of new systems and services often also requires changes in people’s jobs and in the processes used to accomplish those jobs. Such efforts are intended to increase business value. Such changes require change initiatives because they involve guiding a mixture of stakeholders through the change process. This is one aspect of [http://eitbokwiki.org/Change_Initiatives change management].<br />
Change also occurs when existing systems or services must be updated to meet new needs. Depending on the scope of the proposed changes, a change initiative may be required in this situation, too. At any rate, a change request process must be initiated and tracked to disposition (deferral, rejection, or implementation). Changes also come about as a result of defect reports. In such cases, the defect report must be tracked throughout the report’s life cycle, to disposition (deferral, rejection, or implementation).<br />
These latter types of change management are discussed in detail in the EITBOK’s section on [http://eitbokwiki.org/Operations_and_Support Operations and Support].<br />
===Interoperability of Component Systems===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Interoperability interoperability] for more information. ''<br />
As explained in the [http://eitbokwiki.org/Interoperability#One EITBOK], ''interoperability'' means “the ability of systems (including organizations) to exchange and use exchanged information without knowledge of the characteristics or inner workings of the collaborating systems (or organizations).” This definition is based on an ISO definition: “degree to which two or more systems, products, or components can exchange information and use the information that has been exchanged.” (ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models, 4.2.3.2. ) Note that this definition includes hardware components as well as software systems and the organizations in which they are used.<br />
Because technology changes so rapidly, and organizations themselves are frequently changing, achieving and maintaining interoperability is crucial. It is one of the main reasons that providing IT services is difficult and how it differs from engineering and delivering finished products, whether off-the-shelf products or bespoke systems.<br />
===Security of Systems and Data===<br />
<blockquote><br />
There are only two types of companies: those that have been hacked, and those that will be.<br />
-FBI Director Robert Mueller, October 2012<br />
</blockquote><br />
<br />
<blockquote><br />
There are two kinds of big companies in the United States. There are those who've been hacked by the Chinese and those who don't know that they've been hacked by the Chinese<br />
-FBI Director James Comey, October 2014<br />
</blockquote><br />
''See the EITBOK’s section on [http://eitbokwiki.org/Security security] for additional information. ''<br />
While there are many definitions for security, most include the three dimensions of confidentiality, integrity, and availability (sometimes referred to as the [http://eitbokwiki.org/Glossary#ciatriad CIA triad]). As such, the primary goal of EIT security is to preserve the confidentiality, integrity, and availability of information and information systems. <br />
The principles behind an organization’s [http://eitbokwiki.org/Glossary#isms information security management system] (ISMS) should be to design, implement, and maintain a coherent set of policies, processes, and systems that keep the risks associated with its information assets at a tolerable level, and yet, manage the cost and inconvenience of said risk management. As such, the goals of EIT security are to:<br />
* Always understand the current risk tolerance of the enterprise with respect to information and device security.<br />
* Understand the security threats and potential damages to information, devices, and individuals.<br />
* Create and follow policies and procedures that keep cyberattack risk and damages at or below a tolerable level.<br />
* Effectively and efficiently detect and deal with<br />
[http://eitbokwiki.org/Security#One cyberattack incidents].<br />
Ensuring security in EIT has been made even more pressing and more difficult by the proliferation of mobile devices in enterprises and their ever-increasing use to conduct business. Increasingly, personal devices (Bring Your Own Device – BYOD) are used, accessing both corporate networks and public networks. The cost of [https://www.checkpoint.com/downloads/products/check-point-mobile-security-survey-report2013.pdf mobile security incidents] very easily can outweigh the cost of the mobile device itself. <br />
==Quality of Systems and Services==<br />
The Enterprise ''Information'' Technology organization has, since its origins, had as its primary responsibility the timely provision of information to the larger organization. The information is expected to be not only timely, but also accurate and relevant. While the EIT organization itself may not be responsible for creating the data, it is responsible for the physical and logical validity and [https://simplicable.com/new/data-integrity-vs-data-quality integrity of the data] that is used to construct information. It is for this reason that defining and using appropriate processes is essential to ensure high-quality operation, including the development or acquisition, implementation and integration of new or changed capabilities.<br />
The EITBoK details the quality concepts of<br />
* How to approach measuring [http://eitbokwiki.org/Quality#Measuring_Quality Quality]<br />
* The importance of Quality in [http://eitbokwiki.org/Quality#Requirements_Management Requirements Management]<br />
* Understanding an organization’s [http://eitbokwiki.org/Quality#Quality_Capability Quality Capability]<br />
* The differences between [http://eitbokwiki.org/Quality#QMS_and_QC_vs._QA QMS, QC and QA]<br />
* Cost of Quality in [http://eitbokwiki.org/Quality#Technical_Debt_and_the_Cost_of_Rework Technical Debt and the Cost of Rework]<br />
==Disaster Preparedness==<br />
<br />
As explained in the [http://eitbokwiki.org/Disaster_Preparedness EITBOK], disaster preparedness and [http://eitbokwiki.org/Glossary#dr disaster recovery] (DR) support business-continuity planning and include planning for EIT resiliency, as well as recovery from adversity, so that critical business services affected are restored to a satisfactory working state within an [http://eitbokwiki.org/Glossary#acceptable acceptable] timeframe after an event.<br />
The EITBoK devotes a chapter to how the EIT organization and its parent must plan in advance for how it will provide sufficient organizational resilience to recover from disasters and return to normal operation as rapidly as possible.<br />
It provides the following examples of disasters and service interruptions that could occur and should be considered in prevention and recovery planning:<br />
These are examples of disasters:<br />
* Natural disaster affecting datacenters or EIT service operations (flood, fire, earthquake, wind)<br />
* Security breach resulting in a disaster (destruction of data, admin password changes, virus/malware installation, sabotage)<br />
* Usage error (accidental deletion, unplug/turn off system resulting in corruption)<br />
* Utility failure affecting datacenters (loss of power even after UPS)<br />
* Vendor failure (cloud provider security failure, oil spill)<br />
* Staffing issue (employment dispute/walkout, epidemic)<br />
These are examples of unpreparedness:<br />
* Requiring use of computers or printers when power is out<br />
* Requiring use of Internet when power or connectivity is out<br />
* Single point of knowledge/control for administration access<br />
* Lack of offsite backup storage<br />
* Lack of working restoration from backups<br />
* Lack of failover datacenters in separate locations<br />
* Undocumented or out-of-date documentation for system interfaces<br />
*Requiring use of phones that are out of power<br />
* Lack of designation of leaders in restoration efforts (who is in charge of restoring service and they know they are in charge)<br />
* In general, no cohesive, comprehensive EIT service restoration plan<br />
==Operations and Support of Delivered Systems and Services==<br />
[http://eitbokwiki.org/Operations_and_Support Operations and support activities] focus on maintaining an operation normal state in EIT environments, meaning that systems and processes execute according to expectations, with no surprises to users. This desired normal state requires the careful management of EIT assets and services via Operations, as well as of users via Support.<br />
Normal states can be disrupted either by the expected and planned transition of an asset, or by an unexpected event, be it as large as a disaster or by the discovery of a system defect. In the former case, the Disaster Recovery Plan is executed; in the latter, incident management kicks in when a system halts, or problem management is exercised when an operational system is not functioning as expected. The processes needed to ensure effective application of these complex functions is detailed in the [http://eitbokwiki.org/Operations_and_Support#Guiding_Principles Operations and Support Knowledge Area] within the EITBOK. <br />
ISO/IEC/IEEE 20000 may be used by any organization to develop and manage EIT operations, along with the current version of [https://www.servicenow.com ITIL].<br />
ITIL for many is the tool of choice for the operations and infrastructure side of IT, particularly for IT services. <br />
==Ethics==<br />
See the EITBOK’s section on [http://eitbokwiki.org/Ethics ethics] for additional information.<br />
Both the IEEE and ACM require their members to adhere to Codes of Ethics. See the [https://www.ieee.org/about/corporate/governance/p7-8.html IEEE Code of Ethics] and [https://www.acm.org/code-of-ethics ACM Code of Ethics and Professional Conduct]. Both of these can be downloaded freely. In addition, the IEEE Computer Society and the ACM worked together on the [https://dl.acm.org/action/downloadSupplement?doi=10.1145%2F265684.265699&file=acm-se-code-of-ethics.html Software Engineering Code of Ethics] (also available [https://dl.acm.org/doi/10.1145/265684.265699 here]).<br />
The organization should create an easily accessible Code of Ethics:<br />
* Ethical assertions should be documented and socialized in EIT in the form of a Code of Ethics, tied to the overall business code of ethics, and signed off by all staff so that violations can be cause for reprimand or dismissal.<br />
* Vendors should be held to similar ethical standards.<br />
* Lists of employees who have signed off on the Code of Ethics are maintained by EIT governance.<br />
The EITBOK has identified EIT ethical topics that include:<br />
* Those actions and decisions that may be illegal<br />
* Consideration of the social impact of the work at hand—if it will cause harm<br />
* Alignment of business and EIT strategies and policies to an ethical standard<br />
* Incorporation of the ideals of professionalism<br />
* Adherence to applicable regulatory intent<br />
* Protection for whistle blowers<br />
Areas to specifically highlight:<br />
* Activities that interfere with or corrupt the proper function of computers, applications and systems<br />
* Activities that interfere with digital privacy or intellectual rights of others<br />
* Respect for confidentiality, privacy, permissions, and access rights<br />
* Inappropriate bias (skewing) of analysis and reporting<br />
* Inaction in the face of likely ethics violations<br />
==EIT Roles==<br />
Several roles play a part in accomplishing the EIT organization’s mission. Just as a systems engineer can play several roles in a given project, so might several people in an EIT project combine to fulfill the systems engineering function. <br />
The function of EIT systems engineering is to orchestrate systems development, delivery and operation such that the larger organization achieves favorable outcomes in complex environments. Unlike systems projects that are built for known problems, EIT systems may change in unpredictable ways. A primary concern focuses on how quickly systems adapt to change. This entails a type of resiliency based on skills in establishing options and alternative solutions as well as strategies tailored to the volatility of changing needs and available technologies. It also requires expertise in assuring that systems quality is assured from the start.<br />
Different countries, geographic areas and organizations do not always use the same terminology to reference the functions that the roles contributing to systems engineering perform. The following section will provide information about some major international models for defining EIT skills and capabilities. Generally, though, the necessary roles across the product life cycle include these:<br />
* Business Sponsor/Champion<br />
* Enterprise Architect<br />
* Systems Engineer<br />
* Financial Manager<br />
* Application Architect<br />
* Business Analyst and/or Process Analyst<br />
* Data Analyst and/or Data Architect<br />
* Software Engineer and/or Programmer<br />
* Quality Assurance & Testing<br />
* Network Engineer<br />
* Telecoms Engineer<br />
* Integration Expert <br />
* Transition to Operations Manager<br />
* Release Manager<br />
* Availability Manager<br />
* Capacity Manager<br />
* Change Manager<br />
* Configuration Manager<br />
* EIT Operations Manager<br />
* Incident Management<br />
* Problem Manager<br />
* Service Level Manager<br />
* Database Administrator<br />
* Network Manager<br />
* Product Manager<br />
System engineering activities orchestrate the work of these roles so that they function together, rather than in silos or at cross purposes.<br />
==Examples of Systems Engineering in EIT==<br />
Systems Engineering provides a holistic discipline for integrating and managing the contributions of all roles needed to establish and provide EIT products and services. It ensures that a single perspective does not dominate outcomes; instead, it seeks balance among the many disciplines represented above in creating a consistent product or service that meets the interests and needs of enterprise users (and, perhaps, partners). It boils down to common sense, technical sense, knowing when to ask the right questions, and getting the data to support the answers to those questions. System Engineering achieves this via Systems Engineers. In many instances, though, the SE function is accomplished through Project Management approaches using Integrated Product Teams that include technical experts. Thus, although not specifically calling out a Systems Engineering function, the use of IPTs involved the use of SE practices.<br />
A doctoral dissertation from Purdue University performed a survey and causal analysis of project failures and of accidents(Aloisio, 2018). The results were similar to those found in reviews of IBM consulting projects in the 1990s . The following are examples of Systems Engineering interventions that prevented project failures. Almost all point to the lack of the System Engineering balancing act needed for product delivery.<br />
* A widely used document processing product was undergoing a major upgrade. The new VP of Engineering wanted a project review before committing to a schedule. The review showed that the proposed schedule only considered the development effort and did not give sufficient weight to the voices of the testing and documentation organizations, while the needs of the tech support group had been completely overlooked. By establishing an integrated product management team that included technical expertise, as well as expertise in work breakdown and estimating, a realistic effort was defined and the resulting 9-month schedule was met within 3 weeks.<br />
* A Silicon Valley start-up was depending entirely on an offshore development effort to produce its first product. All senior management was in the U.S. The VP of engineering made monthly visits to the development team. The CEO began to feel uneasy about the team’s ability to deliver on schedule sensing that a lot of finger pointing within the development team itself signaled problems. There was no SE or IPT guiding the project. The VP of Engineering seemed unable to sort things out. A project review showed that the probable delivery date was at least 6 months beyond what the CEO was being told. The project was shut down.<br />
* A major player in Human Resource Management had made commitments to deliver a new product. The project involved more than 100 people across the U.S. The delivery date kept slipping. Project roll-out would involve both installation of software and hardware at client sites, as well as installation and staff training at the large, centrally located Client Services organization. Executive Management needed to decide whether to reorganize this very expensive effort or cancel it. Again, the successful solution depended on establishing an effective cross-functional team (IPT) that necessarily included representatives from the technical teams. The IPT was supported by a newly established Project Management Office (PMO). The PMO integrated the geographically disparate efforts by establishing communication channels, as well as common estimating and scheduling practices. The PMO also instituted monthly critical metrics reports to show the IPT bottlenecks and inefficiencies across the project, from development efforts to Client Services set-up to Payroll technical support.<br />
There are far more examples of the lack of systems engineering practices in EIT projects than in their successful use (unfortunately, this seems also to be true in lots of software projects outside of EIT). Systems Engineering provides a holistic discipline for integrating and managing the contributions of all of the roles needed to provide EIT products and services. It ensures that a single perspective does not dominate outcomes.<br />
==Key External Models of EIT Organizational Capability and Maturity==<br />
Because EIT is critical to businesses globally, considerable effort has gone into establishing universal frameworks for EIT skills, along with definitions of levels of capability of each skill. In addition, at least 2 models have been developed for evaluating the organizational performance of EIT. The effectiveness of systems engineering is key to the effectiveness of the EIT organization.<br />
===IT-CMF: IT-Capability Maturity Framework=== <br />
The IT-CMF had its origin in a quality improvement effort at Intel Labs Europe in Ireland. Its intent, as described at the <br />
[https://cio-wiki.org/wiki/IT_Capability_Maturity_Framework_(IT-CMF) CIO Index website] was to quantify and demonstrate the true value impact of IT. IT-CMF is used to measure, develop, and monitor an organization’s EIT capability maturity. It consists of 35 EIT management capabilities organized into four macro capabilities: managing EIT like a business; managing the EIT budget; managing the EIT capability; and managing EIT for business value. Its 35 critical capabilities (CCs) are [http://eitbokwiki.org/Enterprise_IT_Maturity_Assessment described] as “A defined EIT management domain that helps mobilize and deploy EIT-based resources to effect a desired end, often in combination with other resources and capabilities”. <br />
===CMMI: Capability Maturity Model Integration (US)===<br />
The CMMI had its origin in 1987 in a model requested by the U.S. Department of Defense for determining the capability maturity of contractor software development organizations. This became the Capability Maturity Model (CMM). Since then, it has been expanded into a set of Capability Maturity Models, all based on five levels of demonstrably increasing maturity as measured by organization performance. That set was then integrated and became the CMMI. The CMMI set addresses [https://cmmiinstitute.com/dev Development], [https://cmmiinstitute.com/svc Services], [https://cmmiinstitute.com/sm Supplier Management], [https://cmmiinstitute.com/pm People Management], and [https://cmmiinstitute.com/dm Data Management].<br />
===SFIA: Skills Framework for the information Age (Europe, Canada and US)===<br />
The SFIA Framework has been downloaded and used by organizations and individuals in nearly 180 countries. It can be downloaded for free at [https://www.sfia-online.org]. It identifies 97 professional skills across EIT and supporting areas with seven levels of responsibility, which provide generic levels of responsibility, taking into account reflect experience and competency. These describe the behaviors, values, knowledge, and characteristics that an individual should have in order to be considered competent at a particular level.<br />
===E-CF: European Competency Framework (EU)===<br />
The ECF was the first sector-specific implementation of the European Qualifications Framework (EQF). The European Norm (EN) 16234-1 European e-Competence Framework (e-CF) provides a reference of 41 competences as applied at the Information and Communication Technology (ICT) workplace, using a common European reference for competences, skills, knowledge and proficiency levels. The E-CF Explorer web tool is available [https://ecfexplorer.itprofessionalism.org/ online].<br />
===I Competency Dictionary: EIT skills as Defined by METI/ IPA (Japan)===<br />
The Japanese government’s Information-Technology Promotion Agency (IPA), established by the Ministry of Economy, Trade and Industry (METI) developed the ”I Competency Dictionary” (iCD) to support the IT Engineers Examination. It underlies the METI/IPA Skills Standards for IT Professionals, abbreviated as ITSS, established in 2002. ITSS organizes skills within the information services industry into 11 job categories and 35 specialty fields. In each field, there are seven levels of competence based on individual experience and ability to perform. One appealing feature of ITSS is that this standard allows engineers to draw roadmaps for their own futures and career advancement (Career Path). Approximately 90% of large enterprises and over 60% of SMEs in Japan have introduced or are considering using ITSS. Information in English is available at https://www.ipa.go.jp/english/humandev/forth.html.<br />
===ITIL: Information Technology Infrastructure Library===<br />
According to ITLIlibrary.org, the ITIL Open Guide website, “The Information Technology Infrastructure Library (ITIL) defines the organisational structure and skill requirements of an information technology organisation and a set of standard operational management procedures and practices to allow the organisation to manage an IT operation and associated infrastructure. … The [https://www.itlibrary.org/ “library”] itself continues to evolve. This comprises five distinct areas: <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Strategy ITIL Service Strategy]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Design ITIL Service Design]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Transition ITIL Service Transition]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Operation ITIL Service Operation]; and <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Continual_Service_Improvement ITIL Continual Service Improvement].”<br />
It originally grew out of a British government sponsored effort to regularize IT Service Management (ITSM). <br />
==References==<br />
===Works Cited===<br />
Fong, E.N. and A.H. Goldfine. 1989. ''Information Management Directions: The Integration Challenge. '' National Institute of Standards and Technology (NIST) Special Publication 500-167, September 1989. https://csrc.nist.rip/library/NIST%20SP%20500-167.pdf <br />
<br />
Hammer, M., T.H. Davenport and J. Champy. 1986. ''Dispersion and Interconnection: Approaches to Distributed Systems Architecture'', Cambridge, MA: CSC Index Inc. and Hammer and Company, Inc. (June 1986). Available as: https://www.globalaea.org/general/custom.asp?page=Resources <br />
<br />
Hilliard, R. 2015. “Lessons from the fundamental unity of architecting”. ''Software Engineering in the Systems Context'', editors: Ivar Jacobson and Harold 'Bud' Lawson.<br />
<br />
Hofmeister, C. et al. 2007. “A general model of software architecture design derived from five industrial approaches”. ''The Journal of Systems and Software'' 80(1). <br />
<br />
ISO/IEC 25010:2011 ''Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models'', 4.2.3.2.<br />
<br />
ISO/IEC/IEEE 42010 Users Group. ''Survey of Architecture Frameworks'' Available as: http://www.iso-architecture.org/42010/afs/<br />
<br />
ISO/IEC/IEEE. 2011. ISO/IEC/IEEE 42010:2011, ''Systems and software engineering — Architecture description. ''<br />
<br />
PMI. 2013. ''Software Extension to PMBOK® Guide – Fifth Edition. '' Newtown Square, PA, USA: Project Management Institute (PMI). Available as: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/software-extension-5th-edition.<br />
<br />
Rivera, R. 2013. “The PRISM Architecture Framework – Was it the Very First Enterprise Architecture Framework?” ''Journal of Enterprise Architecture'', November 2013<br />
<br />
Zachman, J. 1987. “A Framework for Information Systems Architecture”. ''IBM Systems Journal'', pp454-470, 1987 <br />
<br />
===Primary References===<br />
IEEE Computer Society. ''Enterprise IT Body of Knowledge''. Available: http://eitbokwiki.org<br />
<br />
=-=Additional References===<br />
IT Capability Maturity Framework (IT-CMF): The Body of Knowledge Guide. 2015. Editors. Martin Curley, Jim Kenneally, Marian Carcary. Van Haren Publishing.<br />
<br />
Lessons from Systems Engineering Failures: Determining Why Systems Fail, The State of Systems Engineering Education, and Building an Evidence-Based Network to Help Systems Engineers Identify and Fix Problems on Complex Projects, Diane Constance Aloisio, December 2018.<br />
<br />
===International Standards Guiding EIT===<br />
ANSI/AIAA. 2012. ''ANSI/AIAA Guide to the Preparation of Operational Concept Documents. '' ANSI/AIAA G-043A-2012e.<br />
<br />
IEEE 2012 Std 828™-2012, ''IEEE Standard for Configuration Management in Systems and Software Engineering. ''<br />
<br />
ISO 10004:2012, Quality management—Customer satisfaction—Guidelines for monitoring and measuring<br />
<br />
ISO 10007:2003, Quality management systems—Guidelines for configuration management<br />
<br />
ISO 18238:2015, Space systems—Closed loop problem solving management<br />
<br />
ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models<br />
<br />
ISO/IEC 16350:2015, Information technology—Systems and software engineering—Application management<br />
<br />
ISO/IEC 19770-1:2012, Information technology—Software asset management—Part 1: Processes and tiered assessment of conformance<br />
<br />
ISO/IEC 20000-1:2011, (IEEE Std 20000-1:2013) Information technology—Service management—Part 1: Service management system requirements<br />
<br />
ISO/IEC 20000–2:2012, Information technology—Service management—Part 2: Guidance on the application of service management systems<br />
<br />
ISO/IEC TR 20000–10:2015, Information technology—Service management—Part 10: Concepts and terminology<br />
<br />
ISO/IEC TR 20000–11:2015, Information technology—Service management—Part 11: Guidance on the relationship between ISO/IEC 20000-1:2011 and related frameworks: ITIL®<br />
<br />
ISO/IEC TR 20000-12—Information technology—IT Service management—Part 12: Guidance on the relationship between ISO/IEC 20000-1:2011 and service management frameworks: CMMI-SVC®<br />
<br />
ISO/IEC/IEEE 14764-2006, Software Engineering—Software Lifecycle Processes—Maintenance<br />
<br />
ISO/IEC 15939:2007, Systems and software engineering—Measurement process<br />
<br />
ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description <br />
<br />
<br />
----<br />
<center>[[ Systems Engineering and Economics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Quality Attributes|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=File:EIT_Figure_1_-_Higher_Resolution.png&diff=66939
File:EIT Figure 1 - Higher Resolution.png
2023-05-07T03:54:35Z
<p>Mhaas: Uploaded own work with UploadWizard</p>
<hr />
<div>=={{int:filedesc}}==<br />
{{Information<br />
|description={{en|1=Higher resolution version of EIT Figure 1}}<br />
|date=2023-05-06<br />
|source={{own}}<br />
|author=[[User:Mhaas|Mhaas]]<br />
|permission=<br />
|other versions=<br />
}}<br />
<br />
=={{int:license-header}}==<br />
{{licensing|generic}}<br />
<br />
[[Category:Enterprise Systems Engineering]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Enterprise_IT&diff=66938
Systems Engineering and Enterprise IT
2023-05-07T03:50:52Z
<p>Mhaas: </p>
<hr />
<div>----<br />
'''''Lead Authors:''''' Chuck Walrad and Richard Hilliard<br />
----<br />
This article forms part of the [[Related Disciplines]] knowledge area (KA). It discusses enterprise IT, building upon the concepts and practices of Systems Engineering presented elsewhere in the SEBOK. Systems Engineering is integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of ''engineered technical systems''. <br />
<br />
== Enterprise IT Introduction==<br />
Although it had its origin in the need to improve success rates in U.S. Government outsourcing of technical systems, Systems Engineering is also integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of [https://www.incose.org/about-systems-engineering/system-and-se-definition/systems-engineering-definition#ENGINEERED_SYSTEM engineered technical systems].<br />
Examples of EIT systems include enterprise resource planning, supply chain management and customer relationship management systems, accounting, finance, inventory and order management, marketing, planning, purchasing, and sales.<br />
In the late 1980s and throughout the 1990s, EIT organizations became increasingly aware that the success rates of IT projects were very low, and that their enterprise customers were increasingly unhappy with their EIT investments. The Standish Group sought to understand what was going on. Their findings were presented in the [https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf Chaos Report] (1994):<br />
The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable but could easily be in the trillions of dollars.<br />
As a result, commercial IT organizations, through the auspicious parallel emergence of the Total Quality Management movement and the increasingly widespread development of application development methodologies (ADM) by IT management consulting firms, recognized the need for the principles of Systems Engineering and cross-functional teams (Integrated Product Teams [https://www.sebokwiki.org/wiki/Integrated_Product_Team_(IPT)_(glossary)]. It should be noted that there is considerable overlap today between what constitutes Systems Engineering and what constitutes [[Project and Portfolio Management|Relationships between Systems Engineering and Project Management]] (see [https://www.pmi.org/learning/library/bridging-gap-program-management-systems-engineering-6213 PMI]). This article does not attempt to resolve this issue. Note that the “[[Related Business Activities|following business management activities]] can be ''supported'' by enterprise systems engineering (ESE) activities” [emphasis added]: <br />
* mission and strategic planning,<br />
* business processes and information management,<br />
* performance management,<br />
* portfolio management,<br />
* resource allocation and budgeting, and<br />
* program and project management.<br />
Note that these same areas have been designated as being supported by Project Management Offices. However, since a key difference between project management and systems engineering has been identified as the requirement that the latter includes technical expertise in the product/system of concern, focus should be on systems engineering and integrated product teams (IPTs). <br />
With IPTs, each product is shepherded from concept through delivery and support to retirement by a cross-functional team that includes representatives from each area of responsibility, such as customer requirements development, design and development, test, configuration management, release engineering, delivery, and support.<br />
As enterprises have come to depend more and more on technology to perform effectively, Enterprise IT organizations have matured, often due to the influence of IT consulting firms that make it their business to keep abreast of best practices.<br />
<br />
== EIT Concepts ==<br />
This knowledge area (KA) discusses enterprise IT, building upon the concepts elucidated in the IEEE/ACM ''[http://eitbokwiki.org EITBOK Guide to the Enterprise Information Technology Body of Knowledge]'' and general concepts of Systems Engineering elsewhere in SEBOK. <br />
An enterprise may be viewed from various perspectives: such as a system or a [[system of systems (SoS)|Enterprise Systems Engineering]]:<br />
* system-like enterprise: enterprises, like other systems, may have a tight coupling, single-executive function; <br />
* system of systems-like enterprise: may be a loosely coupled group of organizations with blurred boundaries and (yet) with (some) shared outcomes.<br />
The choice of perspective may vary with many factors: the enterprise itself, the mission or purpose, or the particular engineering task at hand. We can view an enterprise as a system with inputs and outputs in relation to the outside world, or a system of systems interacting through their individual inputs and outputs. <br />
An enterprise usually involves one (or more) organization(s) but need not be identified with the organization. As the scope of human and organizational participants of the enterprise widen, there may be no single point of control. For example, an ''extended enterprise'' could include a company, its suppliers and customers.<br />
Whatever perspective (system-like, SoS-like, other) is taken there are [[key ingredients|Enterprise Systems Engineering Background]] of any enterprise: capabilities, individual (competencies) and the organizational design. [[Capabilities|Enterprise Capability Management]] can be further categorized: “There are three different kinds of capability: organizational capability, system capability, and operational capability.” These capabilities determine what the enterprise is able to produce which may be external offerings or internal mechanisms. Operational capabilities create services and/or products which in turn produce value as determined by stakeholders. The capabilities of an enterprise are realized through [[Enterprise Systems Engineering Background|various enterprise elements]], including: “hardware, software, personnel, facilities, data, materials, techniques, and even services”. which include “soft” items, like people, processes, principles, policies, practices, organizations, doctrine, theories, and beliefs.<br />
EIT capabilities exist through lifecycles spanning from creation through eventual replacement and disposal. ''Life cycle models'' are schemes to aid in the understanding, design, planning and management of the capability of interest. <br />
“A life cycle for a system generally consists of a series of stages regulated by a set of management decisions which confirm that the system is mature enough to leave one stage and enter another.” Basic life cycle terms and concepts are discussed in [[System Lifecycle Approaches]]. Some typical life cycles are discussed in [[System Lifecycle Models]].<br />
A life cycle-based approach can be deployed across the several levels and used to manage evolution. These levels are:<br />
* the enterprise itself,<br />
* the processes and organizations constituting the enterprise,<br />
* the systems enabling the capabilities, services or products provided. <br />
It is important to distinguish between ''product'' and ''project'' lifecycle models. A product’s life cycle extends from its initial concept approval, through development and distribution, to its retirement. This is the cycle that is managed within an Enterprise IT organization, since EIT must manage the hardware or software product from its introduction, in the case of acquired capabilities, or from its concept approval and development, in the case of capabilities it builds, through its deployment, maintenance and eventual retirement (withdrawal). Each of these stages is usually managed as a project or a series of projects.<br />
However, most discussions of life cycles within software and systems discussions focus on ''project'' life cycles. See, for example, the ''Software Extension to PMBOK Guide'' (PMI 2013).<br />
==System of Systems Context in EIT==<br />
“Enterprise IT” (EIT) is used both to refer to the technology organization/business unit within the enterprise and to the enterprise’s information technology systems. In this article, we use EIT to refer to the technology systems. When referring to the organization, we use the phrase “Enterprise IT organization” or EIT organization. <br />
Enterprise IT organizations are responsible for complex socio-technical systems. Socio-technical systems in a business context (thus, EIT) contain technical elements (software, hardware, networks, storage, databases, etc.) but they also contain essential human components and necessary business processes. As covered in [[Introduction to Systems Engineering Fundamentals]], they exist in an engineered System Context that is a set of system component interrelationships within a real-world environment:<br />
This includes where problems come from and how they are defined, how we identify and select candidate solutions, how to balance technology and human elements in the wider solution context, how to manage the complex organizational systems needed to develop new solutions, and how developed solutions are used, sustained and disposed of. … Systems Engineering should consider the full Engineered System Context so that the necessary understanding can be reached and the right systems engineering decisions can be made. <br />
Socio-technical systems also have the following key characteristics: ''Openness'' in that they strongly interact with their environments, and ''unfinished'' in that they evolve over time.<br />
A complex of EIT systems is essential to the successful functioning of the humans in the enterprise. They rely on EIT’s technology for communication, for paying employees, for people management, for business measurement, and often for managing supply chains. Thus, “EIT needs to be viewed as a strategic partner to all the other functions and business units within an enterprise. This means that the results produced by EIT along with its effectiveness and efficiency are all critically important to the success of the enterprise.” [http://eitbokwiki.org/What_is_the_Enterprise_Perspective%3F]<br />
To accomplish this mission, the EIT organization builds and acquires new systems or system components, integrates them into the mega System of Systems, and maintains the integrity and interoperability of the individual components, but also the integrity of the entire complex of systems. In addition, security and performance levels must be achieved, benchmarked and maintained or improved.<br />
==Major concerns of the EIT Organization==<br />
The [http://eitbokwiki.org ''Enterprise IT Body of Knowledge''] provides a good deal of information about these major concerns, which we will not replicate here. Rather, links to the relevant areas are provided. The EITBOK demonstrates how, in providing technology systems and services to the enterprise, the EIT organization must skillfully manage such concerns as the following.<br />
<br />
===Enterprise Architecture===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Enterprise_Architecture Enterprise Architecture] for additional information. ''<br />
[http://eitbokwiki.org/Glossary#ea ''Enterprise architecture''] (EA) is the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. EA applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their organization's strategies. Enterprise architecture builds upon many of the concepts and practices of [[System Architecture Definition|systems architecture]] and also software architecture [https://www.sebokwiki.org/wiki/System_Architecture_Definition].<br />
This section will discuss Enterprise Architecture from the perspective of key [[Principles of Systems Thinking]], designated in this article with '''''bold italics'''''. There are many commonalities in architecture whether one is architecture systems, software or the enterprise [Unity]. In this article we highlight both commonalities and differences between Enterprise Architecture and Systems Architecture. <br />
Architecture takes place at the juncture of design problems and their solutions. Design problems rarely arrive fully formulated or “hatched” for the architect; much of the architecture effort is to analyze or formulate the problems to be solved. Often this involves negotiation both within the enterprise and with outside stakeholders. Possible solutions are limited by resources and schedule and therefore often must also be negotiated.<br />
A dominant principle of Enterprise Architecture is '''''separation of concerns''''' (SoC). This is due to the complexity of enterprises, with many forces acting upon them; the many technologies and disciplines involved in their creation and day-to-day operations; and due to the diversity of stakeholders involved in the enterprise (see [[EIT Roles]]). <br />
An application of SoC is the '''''boundary''''' principle which is crucial to separate what is “inside” the enterprise from what is “outside”. While the former is often under the enterprise’s control, the latter is often beyond its control. <br />
For some systems, determining the boundary is a key decision, subject to many possibilities and consequences. This is perhaps less the case for enterprises whose bounds are determined by the extent of organizations, regulations, supply chains or other criteria. Within an established boundary, the '''''holism''''' principle applies: to treat the enterprise as a unified whole, and, in particular, with respect to the '''''interaction''''' of the enterprise with its ''environment''—including stakeholders, other enterprises and systems. From an enterprise IT perspective, an enterprise is a ''system of systems. '' SoC offers a way to focus on the constituent systems in terms of their interconnections to one another to form the enterprise.<br />
Another useful application of SoC is to apply the principle of '''''multiple views''''' to depict the architecture of the enterprise in different ways to address the diverse interests (i.e., ''concerns'') of an enterprise’s various stakeholders. Each ''architecture view'' presents a specific perspective on the enterprise. To be understandable to its audiences (those various stakeholders), each view should follow the conventions of its ''architecture viewpoint'' (ISO/IEC/IEEE 42010 2011). Just as a map should have a legend, each view should have a documented viewpoint providing a prescribed set of conventions for looking at the enterprise through the resulting view. A viewpoint definition serves as a contract between the architect and stakeholders on ''how'' a selected set of concerns are to be addressed. Each viewpoint allows the architect to consider the enterprise in terms of various kinds of elements and relations among them and to present that view to those “concerned” stakeholders. Dominating concerns in enterprise architecture include interoperability, quality of systems and services, operations, managing change, and alignment with the enterprise’s mission, market, and technology. Via the principle of '''''dualism''''', we recognize that some viewpoints are paired, such as with process/data duality. Another pervasive duality in the enterprise is of people/technology in terms of what capabilities are automated and which are performed by people.<br />
In support of enterprise architecture, there are numerous ''enterprise architecture frameworks'' each providing a pre-defined, integrated set of viewpoints to frame typical, recurring concerns (ISO/IEC/IEEE 42010 Users Group 2022). The earliest recorded framework was (Hammer et al. 1986), developed in the mid-1980s in response to growing availability of distributed computing to the enterprise (Rivera 2013). In the late 1980s, US NIST created its Enterprise Architecture Model as a guide for US federal departments to organize their IT offerings (Fong and Goldfine 1989). NIST’s 5-layer model remains influential today. Despite never using the term “enterprise,” Zachman’s information systems architecture has had a major influence on how subsequent frameworks have been organized and depicted using grids or cubes. Later frameworks have evolved in response to emerging concepts, such as the move from client-server to service-oriented applications, as in the OASIS SOA Reference Model and its associated framework. The 1990s saw a proliferation of frameworks for defense enterprises including US DODAF, UK MODAF, NATO’s NAF and led to successors such as OMG’s UAF.<br />
Yet another application of '''''separation of concerns''''' is distinguishing today’s needs versus facilitating future needs; balancing '''''stability/change''''' and highlighting the temporal planning aspect of architecture of the enterprise. In concert with applying SOC, the architect uses the principle of '''''abstraction''''' to “forget” some details of the subject and thus focus on essentials. Just as SoC is a way of taking things apart, '''''abstraction''''' is a way of unifying or putting like things together through generalization. These two principles are perhaps the most central to architecture. SoC and abstraction work together: SoC picks out subjects and abstraction helps architects to focus upon the essentials of each subject. <br />
Returning to the '''''boundary''''' and '''''holism''''' principles, the enterprise architect applies these recursively. As architecting proceeds, the internal details of the enterprise become known in terms of '''''interaction''''' among its parts and other '''''relations'''''. Again, '''''multiple views''''' are used to factor specific '''''relations'''''into distinct views. Typical relations include Causality, Dependency, Client-Server, and Input-Output. <br />
There are a variety of ways to structure the enterprise based upon stakeholder needs, mission or charter, technologies or capabilities already in place. Among these are structuring principles including: <br />
* '''''Modularity''''' (separate and group capabilities into modules by commonalities); <br />
* '''''Network''''' (modules are linked together); <br />
* '''''Encapsulation''''' (separating architecture modules use from how they are implemented); <br />
* '''''Layer Hierarchy''''' (separation through gradual refinement); <br />
* ''''' Regularity''''' (uniformity of interactions, of structure within layer, within network). <br />
* ''''' Similarity/Difference''''' (recognizing the limits of Regularity)<br />
A simple pattern for architecture has been defined (Hofmeister ''et al. '' 2007). Its elements are Analysis, Synthesis and Evaluation. See Figure 1 below. <br />
''Architecture Analysis'' formulates architecturally-significant requirements (ASRs)—those requirements which influence an enterprise’s architecture. Architecture analysis is based on identified concerns and other information based on understanding the enterprise’s environment, known requirements, stakeholder needs and any constraints. ASRs reflect the “design problems” that the architecture must solve. In many cases, negotiations take place to modify incoming needs, requirements and expectations to make solutions possible. The result of this activity takes the form of ASRs, including architecture principles and initial enterprise-wide decisions.<br />
''Architecture Synthesis'' develops candidate solutions in response to the concerns and ASRs. During Synthesis the architect works out the details of solutions to the identified design problems, tradeoff and interactions between them which are likely to generate further design problems. Synthesis elaborates the ASRs, principles and initial decisions into more detailed solution elements. The principle of ''''' EQUIFINALITY''''' reminds us that for many stable situations (i.e., states of the enterprise), there are many ways to reach those states.<br />
''Architecture Evaluation'' validates whether chosen solutions satisfy ASRs or whether rework is needed (ISO/IEC/IEEE 42030 2019).<br />
Applying the principles discussed above is pervasive in enacting the Analysis–Synthesis–Evaluation pattern iteratively. <br />
<br />
[[File:SEBoK EIT Figure 1.png|centre|thumb|2000px|'''Figure 1. A pattern for Architecture.''']] <br />
<br />
While there are many commonalities among EIT, systems and software architectures, Figure 2 addresses the relationships ''between'' them. Viewing an enterprise as a system, the EIT architecture governs the fundamental IT decisions of the enterprise. That enterprise might be extended to “outsiders” such as vendors, suppliers and perhaps customers. Depending upon the enterprise, the ''governs'' relationship may entail very strict rules or loose guidance. <br />
Within the enterprise, the ecosystem of systems, applications and data may be viewed as a system of systems. The EIT Architecture constrains the architectures governing individual systems, applications and data stores within the enterprise, so that these are able to interoperate and otherwise “play nicely” together.<br />
<br />
[[File:EIT Figure 2.png|centre|thumb|1000px|'''Figure 2. Relating Enterprise IT, Systems and Software Architecture.''']] <br />
<br />
===Strategy and Governance===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance] for additional information. ''<br />
<blockquote><br />
[http://eitbokwiki.org/Glossary#eit Enterprise information technology] (EIT) governance is the established process of defining the strategy for the EIT organization and overseeing its execution to achieve enterprise goals. Strategic planning translates the larger enterprise’s goals into EIT goals and defines what EIT must do to achieve those goals. This effort then communicates this hierarchy of goals: EIT goals as well as how they support the enterprise’s goals. EIT governance drives needed changes to achieve those goals, while maintaining agreed levels of operation. Taking into account various perspectives (such as financial, historical, environmental, and future projections), a strategic plan is a roadmap for action and change, both vertically and horizontally, across the EIT organization. The EIT organization’s strategic plans are based on the enterprise’s strategic plans, focusing on EIT’s role in them; EIT governance provides a monitoring and control framework to achieve strategic goals and objectives. Thus, EIT governance is essential for achieving the EIT strategy and goals..<br />
-[http://eitbokwiki.org/Strategy_and_Governance EITBOK wiki]<br />
</blockquote><br />
<br />
The principle of ''''' PARSIMONY''''' applies here, too (see [[Principles of Systems Thinking]]). These principles will be designated in this article with '''''bold italics'''''. For example, the simplest possible measurement and reporting systems are most likely to be used and not corrupted. Similarly, the EIT organizational structure should be straightforward and easy to traverse so that staff can communicate and problem-solve in teams.<br />
In governing the EIT organization to meet its dual goals of satisfying its customers and meeting its budget and schedule commitments, EIT management encounters the difficulty of managing in the face of '''''dualism''''', “ensuring a constant dynamic balance often through a cyclic dominance of one element and then the other”. The most obvious instance of handling ''''' dualism''''' in EIT is the trade-off between budget, project prioritization and features within projects.<br />
===Change===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Change_Initiatives Change Initiatives] for more information. ''<br />
There are two levels of change management discussed in the EITBOK: organizational change management and changes to the IT organization’s assets, whether they be software, hardware, or telecommunications systems.<br />
In the larger sense, the introduction of new systems and services often also requires changes in people’s jobs and in the processes used to accomplish those jobs. Such efforts are intended to increase business value. Such changes require change initiatives because they involve guiding a mixture of stakeholders through the change process. This is one aspect of [http://eitbokwiki.org/Change_Initiatives change management].<br />
Change also occurs when existing systems or services must be updated to meet new needs. Depending on the scope of the proposed changes, a change initiative may be required in this situation, too. At any rate, a change request process must be initiated and tracked to disposition (deferral, rejection, or implementation). Changes also come about as a result of defect reports. In such cases, the defect report must be tracked throughout the report’s life cycle, to disposition (deferral, rejection, or implementation).<br />
These latter types of change management are discussed in detail in the EITBOK’s section on [http://eitbokwiki.org/Operations_and_Support Operations and Support].<br />
===Interoperability of Component Systems===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Interoperability interoperability] for more information. ''<br />
As explained in the [http://eitbokwiki.org/Interoperability#One EITBOK], ''interoperability'' means “the ability of systems (including organizations) to exchange and use exchanged information without knowledge of the characteristics or inner workings of the collaborating systems (or organizations).” This definition is based on an ISO definition: “degree to which two or more systems, products, or components can exchange information and use the information that has been exchanged.” (ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models, 4.2.3.2. ) Note that this definition includes hardware components as well as software systems and the organizations in which they are used.<br />
Because technology changes so rapidly, and organizations themselves are frequently changing, achieving and maintaining interoperability is crucial. It is one of the main reasons that providing IT services is difficult and how it differs from engineering and delivering finished products, whether off-the-shelf products or bespoke systems.<br />
===Security of Systems and Data===<br />
<blockquote><br />
There are only two types of companies: those that have been hacked, and those that will be.<br />
-FBI Director Robert Mueller, October 2012<br />
</blockquote><br />
<br />
<blockquote><br />
There are two kinds of big companies in the United States. There are those who've been hacked by the Chinese and those who don't know that they've been hacked by the Chinese<br />
-FBI Director James Comey, October 2014<br />
</blockquote><br />
''See the EITBOK’s section on [http://eitbokwiki.org/Security security] for additional information. ''<br />
While there are many definitions for security, most include the three dimensions of confidentiality, integrity, and availability (sometimes referred to as the [http://eitbokwiki.org/Glossary#ciatriad CIA triad]). As such, the primary goal of EIT security is to preserve the confidentiality, integrity, and availability of information and information systems. <br />
The principles behind an organization’s [http://eitbokwiki.org/Glossary#isms information security management system] (ISMS) should be to design, implement, and maintain a coherent set of policies, processes, and systems that keep the risks associated with its information assets at a tolerable level, and yet, manage the cost and inconvenience of said risk management. As such, the goals of EIT security are to:<br />
* Always understand the current risk tolerance of the enterprise with respect to information and device security.<br />
* Understand the security threats and potential damages to information, devices, and individuals.<br />
* Create and follow policies and procedures that keep cyberattack risk and damages at or below a tolerable level.<br />
* Effectively and efficiently detect and deal with<br />
[http://eitbokwiki.org/Security#One cyberattack incidents].<br />
Ensuring security in EIT has been made even more pressing and more difficult by the proliferation of mobile devices in enterprises and their ever-increasing use to conduct business. Increasingly, personal devices (Bring Your Own Device – BYOD) are used, accessing both corporate networks and public networks. The cost of [https://www.checkpoint.com/downloads/products/check-point-mobile-security-survey-report2013.pdf mobile security incidents] very easily can outweigh the cost of the mobile device itself. <br />
==Quality of Systems and Services==<br />
The Enterprise ''Information'' Technology organization has, since its origins, had as its primary responsibility the timely provision of information to the larger organization. The information is expected to be not only timely, but also accurate and relevant. While the EIT organization itself may not be responsible for creating the data, it is responsible for the physical and logical validity and [https://simplicable.com/new/data-integrity-vs-data-quality integrity of the data] that is used to construct information. It is for this reason that defining and using appropriate processes is essential to ensure high-quality operation, including the development or acquisition, implementation and integration of new or changed capabilities.<br />
The EITBoK details the quality concepts of<br />
* How to approach measuring [http://eitbokwiki.org/Quality#Measuring_Quality Quality]<br />
* The importance of Quality in [http://eitbokwiki.org/Quality#Requirements_Management Requirements Management]<br />
* Understanding an organization’s [http://eitbokwiki.org/Quality#Quality_Capability Quality Capability]<br />
* The differences between [http://eitbokwiki.org/Quality#QMS_and_QC_vs._QA QMS, QC and QA]<br />
* Cost of Quality in [http://eitbokwiki.org/Quality#Technical_Debt_and_the_Cost_of_Rework Technical Debt and the Cost of Rework]<br />
==Disaster Preparedness==<br />
<br />
As explained in the [http://eitbokwiki.org/Disaster_Preparedness EITBOK], disaster preparedness and [http://eitbokwiki.org/Glossary#dr disaster recovery] (DR) support business-continuity planning and include planning for EIT resiliency, as well as recovery from adversity, so that critical business services affected are restored to a satisfactory working state within an [http://eitbokwiki.org/Glossary#acceptable acceptable] timeframe after an event.<br />
The EITBoK devotes a chapter to how the EIT organization and its parent must plan in advance for how it will provide sufficient organizational resilience to recover from disasters and return to normal operation as rapidly as possible.<br />
It provides the following examples of disasters and service interruptions that could occur and should be considered in prevention and recovery planning:<br />
These are examples of disasters:<br />
* Natural disaster affecting datacenters or EIT service operations (flood, fire, earthquake, wind)<br />
* Security breach resulting in a disaster (destruction of data, admin password changes, virus/malware installation, sabotage)<br />
* Usage error (accidental deletion, unplug/turn off system resulting in corruption)<br />
* Utility failure affecting datacenters (loss of power even after UPS)<br />
* Vendor failure (cloud provider security failure, oil spill)<br />
* Staffing issue (employment dispute/walkout, epidemic)<br />
These are examples of unpreparedness:<br />
* Requiring use of computers or printers when power is out<br />
* Requiring use of Internet when power or connectivity is out<br />
* Single point of knowledge/control for administration access<br />
* Lack of offsite backup storage<br />
* Lack of working restoration from backups<br />
* Lack of failover datacenters in separate locations<br />
* Undocumented or out-of-date documentation for system interfaces<br />
*Requiring use of phones that are out of power<br />
* Lack of designation of leaders in restoration efforts (who is in charge of restoring service and they know they are in charge)<br />
* In general, no cohesive, comprehensive EIT service restoration plan<br />
==Operations and Support of Delivered Systems and Services==<br />
[http://eitbokwiki.org/Operations_and_Support Operations and support activities] focus on maintaining an operation normal state in EIT environments, meaning that systems and processes execute according to expectations, with no surprises to users. This desired normal state requires the careful management of EIT assets and services via Operations, as well as of users via Support.<br />
Normal states can be disrupted either by the expected and planned transition of an asset, or by an unexpected event, be it as large as a disaster or by the discovery of a system defect. In the former case, the Disaster Recovery Plan is executed; in the latter, incident management kicks in when a system halts, or problem management is exercised when an operational system is not functioning as expected. The processes needed to ensure effective application of these complex functions is detailed in the [http://eitbokwiki.org/Operations_and_Support#Guiding_Principles Operations and Support Knowledge Area] within the EITBOK. <br />
ISO/IEC/IEEE 20000 may be used by any organization to develop and manage EIT operations, along with the current version of [https://www.servicenow.com ITIL].<br />
ITIL for many is the tool of choice for the operations and infrastructure side of IT, particularly for IT services. <br />
==Ethics==<br />
See the EITBOK’s section on [http://eitbokwiki.org/Ethics ethics] for additional information.<br />
Both the IEEE and ACM require their members to adhere to Codes of Ethics. See the [https://www.ieee.org/about/corporate/governance/p7-8.html IEEE Code of Ethics] and [https://www.acm.org/code-of-ethics ACM Code of Ethics and Professional Conduct]. Both of these can be downloaded freely. In addition, the IEEE Computer Society and the ACM worked together on the [https://dl.acm.org/action/downloadSupplement?doi=10.1145%2F265684.265699&file=acm-se-code-of-ethics.html Software Engineering Code of Ethics] (also available [https://dl.acm.org/doi/10.1145/265684.265699 here]).<br />
The organization should create an easily accessible Code of Ethics:<br />
* Ethical assertions should be documented and socialized in EIT in the form of a Code of Ethics, tied to the overall business code of ethics, and signed off by all staff so that violations can be cause for reprimand or dismissal.<br />
* Vendors should be held to similar ethical standards.<br />
* Lists of employees who have signed off on the Code of Ethics are maintained by EIT governance.<br />
The EITBOK has identified EIT ethical topics that include:<br />
* Those actions and decisions that may be illegal<br />
* Consideration of the social impact of the work at hand—if it will cause harm<br />
* Alignment of business and EIT strategies and policies to an ethical standard<br />
* Incorporation of the ideals of professionalism<br />
* Adherence to applicable regulatory intent<br />
* Protection for whistle blowers<br />
Areas to specifically highlight:<br />
* Activities that interfere with or corrupt the proper function of computers, applications and systems<br />
* Activities that interfere with digital privacy or intellectual rights of others<br />
* Respect for confidentiality, privacy, permissions, and access rights<br />
* Inappropriate bias (skewing) of analysis and reporting<br />
* Inaction in the face of likely ethics violations<br />
==EIT Roles==<br />
Several roles play a part in accomplishing the EIT organization’s mission. Just as a systems engineer can play several roles in a given project, so might several people in an EIT project combine to fulfill the systems engineering function. <br />
The function of EIT systems engineering is to orchestrate systems development, delivery and operation such that the larger organization achieves favorable outcomes in complex environments. Unlike systems projects that are built for known problems, EIT systems may change in unpredictable ways. A primary concern focuses on how quickly systems adapt to change. This entails a type of resiliency based on skills in establishing options and alternative solutions as well as strategies tailored to the volatility of changing needs and available technologies. It also requires expertise in assuring that systems quality is assured from the start.<br />
Different countries, geographic areas and organizations do not always use the same terminology to reference the functions that the roles contributing to systems engineering perform. The following section will provide information about some major international models for defining EIT skills and capabilities. Generally, though, the necessary roles across the product life cycle include these:<br />
* Business Sponsor/Champion<br />
* Enterprise Architect<br />
* Systems Engineer<br />
* Financial Manager<br />
* Application Architect<br />
* Business Analyst and/or Process Analyst<br />
* Data Analyst and/or Data Architect<br />
* Software Engineer and/or Programmer<br />
* Quality Assurance & Testing<br />
* Network Engineer<br />
* Telecoms Engineer<br />
* Integration Expert <br />
* Transition to Operations Manager<br />
* Release Manager<br />
* Availability Manager<br />
* Capacity Manager<br />
* Change Manager<br />
* Configuration Manager<br />
* EIT Operations Manager<br />
* Incident Management<br />
* Problem Manager<br />
* Service Level Manager<br />
* Database Administrator<br />
* Network Manager<br />
* Product Manager<br />
System engineering activities orchestrate the work of these roles so that they function together, rather than in silos or at cross purposes.<br />
==Examples of Systems Engineering in EIT==<br />
Systems Engineering provides a holistic discipline for integrating and managing the contributions of all roles needed to establish and provide EIT products and services. It ensures that a single perspective does not dominate outcomes; instead, it seeks balance among the many disciplines represented above in creating a consistent product or service that meets the interests and needs of enterprise users (and, perhaps, partners). It boils down to common sense, technical sense, knowing when to ask the right questions, and getting the data to support the answers to those questions. System Engineering achieves this via Systems Engineers. In many instances, though, the SE function is accomplished through Project Management approaches using Integrated Product Teams that include technical experts. Thus, although not specifically calling out a Systems Engineering function, the use of IPTs involved the use of SE practices.<br />
A doctoral dissertation from Purdue University performed a survey and causal analysis of project failures and of accidents(Aloisio, 2018). The results were similar to those found in reviews of IBM consulting projects in the 1990s . The following are examples of Systems Engineering interventions that prevented project failures. Almost all point to the lack of the System Engineering balancing act needed for product delivery.<br />
* A widely used document processing product was undergoing a major upgrade. The new VP of Engineering wanted a project review before committing to a schedule. The review showed that the proposed schedule only considered the development effort and did not give sufficient weight to the voices of the testing and documentation organizations, while the needs of the tech support group had been completely overlooked. By establishing an integrated product management team that included technical expertise, as well as expertise in work breakdown and estimating, a realistic effort was defined and the resulting 9-month schedule was met within 3 weeks.<br />
* A Silicon Valley start-up was depending entirely on an offshore development effort to produce its first product. All senior management was in the U.S. The VP of engineering made monthly visits to the development team. The CEO began to feel uneasy about the team’s ability to deliver on schedule sensing that a lot of finger pointing within the development team itself signaled problems. There was no SE or IPT guiding the project. The VP of Engineering seemed unable to sort things out. A project review showed that the probable delivery date was at least 6 months beyond what the CEO was being told. The project was shut down.<br />
* A major player in Human Resource Management had made commitments to deliver a new product. The project involved more than 100 people across the U.S. The delivery date kept slipping. Project roll-out would involve both installation of software and hardware at client sites, as well as installation and staff training at the large, centrally located Client Services organization. Executive Management needed to decide whether to reorganize this very expensive effort or cancel it. Again, the successful solution depended on establishing an effective cross-functional team (IPT) that necessarily included representatives from the technical teams. The IPT was supported by a newly established Project Management Office (PMO). The PMO integrated the geographically disparate efforts by establishing communication channels, as well as common estimating and scheduling practices. The PMO also instituted monthly critical metrics reports to show the IPT bottlenecks and inefficiencies across the project, from development efforts to Client Services set-up to Payroll technical support.<br />
There are far more examples of the lack of systems engineering practices in EIT projects than in their successful use (unfortunately, this seems also to be true in lots of software projects outside of EIT). Systems Engineering provides a holistic discipline for integrating and managing the contributions of all of the roles needed to provide EIT products and services. It ensures that a single perspective does not dominate outcomes.<br />
==Key External Models of EIT Organizational Capability and Maturity==<br />
Because EIT is critical to businesses globally, considerable effort has gone into establishing universal frameworks for EIT skills, along with definitions of levels of capability of each skill. In addition, at least 2 models have been developed for evaluating the organizational performance of EIT. The effectiveness of systems engineering is key to the effectiveness of the EIT organization.<br />
===IT-CMF: IT-Capability Maturity Framework=== <br />
The IT-CMF had its origin in a quality improvement effort at Intel Labs Europe in Ireland. Its intent, as described at the <br />
[https://cio-wiki.org/wiki/IT_Capability_Maturity_Framework_(IT-CMF) CIO Index website] was to quantify and demonstrate the true value impact of IT. IT-CMF is used to measure, develop, and monitor an organization’s EIT capability maturity. It consists of 35 EIT management capabilities organized into four macro capabilities: managing EIT like a business; managing the EIT budget; managing the EIT capability; and managing EIT for business value. Its 35 critical capabilities (CCs) are [http://eitbokwiki.org/Enterprise_IT_Maturity_Assessment described] as “A defined EIT management domain that helps mobilize and deploy EIT-based resources to effect a desired end, often in combination with other resources and capabilities”. <br />
===CMMI: Capability Maturity Model Integration (US)===<br />
The CMMI had its origin in 1987 in a model requested by the U.S. Department of Defense for determining the capability maturity of contractor software development organizations. This became the Capability Maturity Model (CMM). Since then, it has been expanded into a set of Capability Maturity Models, all based on five levels of demonstrably increasing maturity as measured by organization performance. That set was then integrated and became the CMMI. The CMMI set addresses [https://cmmiinstitute.com/dev Development], [https://cmmiinstitute.com/svc Services], [https://cmmiinstitute.com/sm Supplier Management], [https://cmmiinstitute.com/pm People Management], and [https://cmmiinstitute.com/dm Data Management].<br />
===SFIA: Skills Framework for the information Age (Europe, Canada and US)===<br />
The SFIA Framework has been downloaded and used by organizations and individuals in nearly 180 countries. It can be downloaded for free at [https://www.sfia-online.org]. It identifies 97 professional skills across EIT and supporting areas with seven levels of responsibility, which provide generic levels of responsibility, taking into account reflect experience and competency. These describe the behaviors, values, knowledge, and characteristics that an individual should have in order to be considered competent at a particular level.<br />
===E-CF: European Competency Framework (EU)===<br />
The ECF was the first sector-specific implementation of the European Qualifications Framework (EQF). The European Norm (EN) 16234-1 European e-Competence Framework (e-CF) provides a reference of 41 competences as applied at the Information and Communication Technology (ICT) workplace, using a common European reference for competences, skills, knowledge and proficiency levels. The E-CF Explorer web tool is available [https://ecfexplorer.itprofessionalism.org/ online].<br />
===I Competency Dictionary: EIT skills as Defined by METI/ IPA (Japan)===<br />
The Japanese government’s Information-Technology Promotion Agency (IPA), established by the Ministry of Economy, Trade and Industry (METI) developed the ”I Competency Dictionary” (iCD) to support the IT Engineers Examination. It underlies the METI/IPA Skills Standards for IT Professionals, abbreviated as ITSS, established in 2002. ITSS organizes skills within the information services industry into 11 job categories and 35 specialty fields. In each field, there are seven levels of competence based on individual experience and ability to perform. One appealing feature of ITSS is that this standard allows engineers to draw roadmaps for their own futures and career advancement (Career Path). Approximately 90% of large enterprises and over 60% of SMEs in Japan have introduced or are considering using ITSS. Information in English is available at https://www.ipa.go.jp/english/humandev/forth.html.<br />
===ITIL: Information Technology Infrastructure Library===<br />
According to ITLIlibrary.org, the ITIL Open Guide website, “The Information Technology Infrastructure Library (ITIL) defines the organisational structure and skill requirements of an information technology organisation and a set of standard operational management procedures and practices to allow the organisation to manage an IT operation and associated infrastructure. … The [https://www.itlibrary.org/ “library”] itself continues to evolve. This comprises five distinct areas: <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Strategy ITIL Service Strategy]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Design ITIL Service Design]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Transition ITIL Service Transition]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Operation ITIL Service Operation]; and <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Continual_Service_Improvement ITIL Continual Service Improvement].”<br />
It originally grew out of a British government sponsored effort to regularize IT Service Management (ITSM). <br />
==References==<br />
===Works Cited===<br />
Fong, E.N. and A.H. Goldfine. 1989. ''Information Management Directions: The Integration Challenge. '' National Institute of Standards and Technology (NIST) Special Publication 500-167, September 1989. https://csrc.nist.rip/library/NIST%20SP%20500-167.pdf <br />
<br />
Hammer, M., T.H. Davenport and J. Champy. 1986. ''Dispersion and Interconnection: Approaches to Distributed Systems Architecture'', Cambridge, MA: CSC Index Inc. and Hammer and Company, Inc. (June 1986). Available as: https://www.globalaea.org/general/custom.asp?page=Resources <br />
<br />
Hilliard, R. 2015. “Lessons from the fundamental unity of architecting”. ''Software Engineering in the Systems Context'', editors: Ivar Jacobson and Harold 'Bud' Lawson.<br />
<br />
Hofmeister, C. et al. 2007. “A general model of software architecture design derived from five industrial approaches”. ''The Journal of Systems and Software'' 80(1). <br />
<br />
ISO/IEC 25010:2011 ''Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models'', 4.2.3.2.<br />
<br />
ISO/IEC/IEEE 42010 Users Group. ''Survey of Architecture Frameworks'' Available as: http://www.iso-architecture.org/42010/afs/<br />
<br />
ISO/IEC/IEEE. 2011. ISO/IEC/IEEE 42010:2011, ''Systems and software engineering — Architecture description. ''<br />
<br />
PMI. 2013. ''Software Extension to PMBOK® Guide – Fifth Edition. '' Newtown Square, PA, USA: Project Management Institute (PMI). Available as: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/software-extension-5th-edition.<br />
<br />
Rivera, R. 2013. “The PRISM Architecture Framework – Was it the Very First Enterprise Architecture Framework?” ''Journal of Enterprise Architecture'', November 2013<br />
<br />
Zachman, J. 1987. “A Framework for Information Systems Architecture”. ''IBM Systems Journal'', pp454-470, 1987 <br />
<br />
===Primary References===<br />
IEEE Computer Society. ''Enterprise IT Body of Knowledge''. Available: http://eitbokwiki.org<br />
<br />
=-=Additional References===<br />
IT Capability Maturity Framework (IT-CMF): The Body of Knowledge Guide. 2015. Editors. Martin Curley, Jim Kenneally, Marian Carcary. Van Haren Publishing.<br />
<br />
Lessons from Systems Engineering Failures: Determining Why Systems Fail, The State of Systems Engineering Education, and Building an Evidence-Based Network to Help Systems Engineers Identify and Fix Problems on Complex Projects, Diane Constance Aloisio, December 2018.<br />
<br />
===International Standards Guiding EIT===<br />
ANSI/AIAA. 2012. ''ANSI/AIAA Guide to the Preparation of Operational Concept Documents. '' ANSI/AIAA G-043A-2012e.<br />
<br />
IEEE 2012 Std 828™-2012, ''IEEE Standard for Configuration Management in Systems and Software Engineering. ''<br />
<br />
ISO 10004:2012, Quality management—Customer satisfaction—Guidelines for monitoring and measuring<br />
<br />
ISO 10007:2003, Quality management systems—Guidelines for configuration management<br />
<br />
ISO 18238:2015, Space systems—Closed loop problem solving management<br />
<br />
ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models<br />
<br />
ISO/IEC 16350:2015, Information technology—Systems and software engineering—Application management<br />
<br />
ISO/IEC 19770-1:2012, Information technology—Software asset management—Part 1: Processes and tiered assessment of conformance<br />
<br />
ISO/IEC 20000-1:2011, (IEEE Std 20000-1:2013) Information technology—Service management—Part 1: Service management system requirements<br />
<br />
ISO/IEC 20000–2:2012, Information technology—Service management—Part 2: Guidance on the application of service management systems<br />
<br />
ISO/IEC TR 20000–10:2015, Information technology—Service management—Part 10: Concepts and terminology<br />
<br />
ISO/IEC TR 20000–11:2015, Information technology—Service management—Part 11: Guidance on the relationship between ISO/IEC 20000-1:2011 and related frameworks: ITIL®<br />
<br />
ISO/IEC TR 20000-12—Information technology—IT Service management—Part 12: Guidance on the relationship between ISO/IEC 20000-1:2011 and service management frameworks: CMMI-SVC®<br />
<br />
ISO/IEC/IEEE 14764-2006, Software Engineering—Software Lifecycle Processes—Maintenance<br />
<br />
ISO/IEC 15939:2007, Systems and software engineering—Measurement process<br />
<br />
ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description <br />
<br />
<br />
----<br />
<center>[[ Systems Engineering and Economics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Quality Attributes|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Enterprise_IT&diff=66937
Systems Engineering and Enterprise IT
2023-05-07T03:50:26Z
<p>Mhaas: </p>
<hr />
<div>----<br />
'''''Lead Authors:''''' Chuck Walrad and Richard Hilliard<br />
----<br />
This article forms part of the [[Related Disciplines]] knowledge area (KA). It discusses enterprise IT, building upon the concepts and practices of Systems Engineering presented elsewhere in the SEBOK. Systems Engineering is integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of ''engineered technical systems''. <br />
<br />
== Enterprise IT Introduction==<br />
Although it had its origin in the need to improve success rates in U.S. Government outsourcing of technical systems, Systems Engineering is also integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of [https://www.incose.org/about-systems-engineering/system-and-se-definition/systems-engineering-definition#ENGINEERED_SYSTEM engineered technical systems].<br />
Examples of EIT systems include enterprise resource planning, supply chain management and customer relationship management systems, accounting, finance, inventory and order management, marketing, planning, purchasing, and sales.<br />
In the late 1980s and throughout the 1990s, EIT organizations became increasingly aware that the success rates of IT projects were very low, and that their enterprise customers were increasingly unhappy with their EIT investments. The Standish Group sought to understand what was going on. Their findings were presented in the [https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf Chaos Report] (1994):<br />
The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable but could easily be in the trillions of dollars.<br />
As a result, commercial IT organizations, through the auspicious parallel emergence of the Total Quality Management movement and the increasingly widespread development of application development methodologies (ADM) by IT management consulting firms, recognized the need for the principles of Systems Engineering and cross-functional teams (Integrated Product Teams [https://www.sebokwiki.org/wiki/Integrated_Product_Team_(IPT)_(glossary)]. It should be noted that there is considerable overlap today between what constitutes Systems Engineering and what constitutes [[Project and Portfolio Management|Relationships between Systems Engineering and Project Management]] (see [https://www.pmi.org/learning/library/bridging-gap-program-management-systems-engineering-6213 PMI]). This article does not attempt to resolve this issue. Note that the “[[Related Business Activities|following business management activities]] can be ''supported'' by enterprise systems engineering (ESE) activities” [emphasis added]: <br />
* mission and strategic planning,<br />
* business processes and information management,<br />
* performance management,<br />
* portfolio management,<br />
* resource allocation and budgeting, and<br />
* program and project management.<br />
Note that these same areas have been designated as being supported by Project Management Offices. However, since a key difference between project management and systems engineering has been identified as the requirement that the latter includes technical expertise in the product/system of concern, focus should be on systems engineering and integrated product teams (IPTs). <br />
With IPTs, each product is shepherded from concept through delivery and support to retirement by a cross-functional team that includes representatives from each area of responsibility, such as customer requirements development, design and development, test, configuration management, release engineering, delivery, and support.<br />
As enterprises have come to depend more and more on technology to perform effectively, Enterprise IT organizations have matured, often due to the influence of IT consulting firms that make it their business to keep abreast of best practices.<br />
<br />
== EIT Concepts ==<br />
This knowledge area (KA) discusses enterprise IT, building upon the concepts elucidated in the IEEE/ACM ''[http://eitbokwiki.org EITBOK Guide to the Enterprise Information Technology Body of Knowledge]'' and general concepts of Systems Engineering elsewhere in SEBOK. <br />
An enterprise may be viewed from various perspectives: such as a system or a [[system of systems (SoS)|Enterprise Systems Engineering]]:<br />
* system-like enterprise: enterprises, like other systems, may have a tight coupling, single-executive function; <br />
* system of systems-like enterprise: may be a loosely coupled group of organizations with blurred boundaries and (yet) with (some) shared outcomes.<br />
The choice of perspective may vary with many factors: the enterprise itself, the mission or purpose, or the particular engineering task at hand. We can view an enterprise as a system with inputs and outputs in relation to the outside world, or a system of systems interacting through their individual inputs and outputs. <br />
An enterprise usually involves one (or more) organization(s) but need not be identified with the organization. As the scope of human and organizational participants of the enterprise widen, there may be no single point of control. For example, an ''extended enterprise'' could include a company, its suppliers and customers.<br />
Whatever perspective (system-like, SoS-like, other) is taken there are [[key ingredients|Enterprise Systems Engineering Background]] of any enterprise: capabilities, individual (competencies) and the organizational design. [[Capabilities|Enterprise Capability Management]] can be further categorized: “There are three different kinds of capability: organizational capability, system capability, and operational capability.” These capabilities determine what the enterprise is able to produce which may be external offerings or internal mechanisms. Operational capabilities create services and/or products which in turn produce value as determined by stakeholders. The capabilities of an enterprise are realized through [[Enterprise Systems Engineering Background|various enterprise elements]], including: “hardware, software, personnel, facilities, data, materials, techniques, and even services”. which include “soft” items, like people, processes, principles, policies, practices, organizations, doctrine, theories, and beliefs.<br />
EIT capabilities exist through lifecycles spanning from creation through eventual replacement and disposal. ''Life cycle models'' are schemes to aid in the understanding, design, planning and management of the capability of interest. <br />
“A life cycle for a system generally consists of a series of stages regulated by a set of management decisions which confirm that the system is mature enough to leave one stage and enter another.” Basic life cycle terms and concepts are discussed in [[System Lifecycle Approaches]]. Some typical life cycles are discussed in [[System Lifecycle Models]].<br />
A life cycle-based approach can be deployed across the several levels and used to manage evolution. These levels are:<br />
* the enterprise itself,<br />
* the processes and organizations constituting the enterprise,<br />
* the systems enabling the capabilities, services or products provided. <br />
It is important to distinguish between ''product'' and ''project'' lifecycle models. A product’s life cycle extends from its initial concept approval, through development and distribution, to its retirement. This is the cycle that is managed within an Enterprise IT organization, since EIT must manage the hardware or software product from its introduction, in the case of acquired capabilities, or from its concept approval and development, in the case of capabilities it builds, through its deployment, maintenance and eventual retirement (withdrawal). Each of these stages is usually managed as a project or a series of projects.<br />
However, most discussions of life cycles within software and systems discussions focus on ''project'' life cycles. See, for example, the ''Software Extension to PMBOK Guide'' (PMI 2013).<br />
==System of Systems Context in EIT==<br />
“Enterprise IT” (EIT) is used both to refer to the technology organization/business unit within the enterprise and to the enterprise’s information technology systems. In this article, we use EIT to refer to the technology systems. When referring to the organization, we use the phrase “Enterprise IT organization” or EIT organization. <br />
Enterprise IT organizations are responsible for complex socio-technical systems. Socio-technical systems in a business context (thus, EIT) contain technical elements (software, hardware, networks, storage, databases, etc.) but they also contain essential human components and necessary business processes. As covered in [[Introduction to Systems Engineering Fundamentals]], they exist in an engineered System Context that is a set of system component interrelationships within a real-world environment:<br />
This includes where problems come from and how they are defined, how we identify and select candidate solutions, how to balance technology and human elements in the wider solution context, how to manage the complex organizational systems needed to develop new solutions, and how developed solutions are used, sustained and disposed of. … Systems Engineering should consider the full Engineered System Context so that the necessary understanding can be reached and the right systems engineering decisions can be made. <br />
Socio-technical systems also have the following key characteristics: ''Openness'' in that they strongly interact with their environments, and ''unfinished'' in that they evolve over time.<br />
A complex of EIT systems is essential to the successful functioning of the humans in the enterprise. They rely on EIT’s technology for communication, for paying employees, for people management, for business measurement, and often for managing supply chains. Thus, “EIT needs to be viewed as a strategic partner to all the other functions and business units within an enterprise. This means that the results produced by EIT along with its effectiveness and efficiency are all critically important to the success of the enterprise.” [http://eitbokwiki.org/What_is_the_Enterprise_Perspective%3F]<br />
To accomplish this mission, the EIT organization builds and acquires new systems or system components, integrates them into the mega System of Systems, and maintains the integrity and interoperability of the individual components, but also the integrity of the entire complex of systems. In addition, security and performance levels must be achieved, benchmarked and maintained or improved.<br />
==Major concerns of the EIT Organization==<br />
The [http://eitbokwiki.org ''Enterprise IT Body of Knowledge''] provides a good deal of information about these major concerns, which we will not replicate here. Rather, links to the relevant areas are provided. The EITBOK demonstrates how, in providing technology systems and services to the enterprise, the EIT organization must skillfully manage such concerns as the following.<br />
<br />
===Enterprise Architecture===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Enterprise_Architecture Enterprise Architecture] for additional information. ''<br />
[http://eitbokwiki.org/Glossary#ea ''Enterprise architecture''] (EA) is the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. EA applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their organization's strategies. Enterprise architecture builds upon many of the concepts and practices of [[System Architecture Definition|systems architecture]] and also software architecture [https://www.sebokwiki.org/wiki/System_Architecture_Definition].<br />
This section will discuss Enterprise Architecture from the perspective of key [[Principles of Systems Thinking]], designated in this article with '''''bold italics'''''. There are many commonalities in architecture whether one is architecture systems, software or the enterprise [Unity]. In this article we highlight both commonalities and differences between Enterprise Architecture and Systems Architecture. <br />
Architecture takes place at the juncture of design problems and their solutions. Design problems rarely arrive fully formulated or “hatched” for the architect; much of the architecture effort is to analyze or formulate the problems to be solved. Often this involves negotiation both within the enterprise and with outside stakeholders. Possible solutions are limited by resources and schedule and therefore often must also be negotiated.<br />
A dominant principle of Enterprise Architecture is '''''separation of concerns''''' (SoC). This is due to the complexity of enterprises, with many forces acting upon them; the many technologies and disciplines involved in their creation and day-to-day operations; and due to the diversity of stakeholders involved in the enterprise (see [[EIT Roles]]). <br />
An application of SoC is the '''''boundary''''' principle which is crucial to separate what is “inside” the enterprise from what is “outside”. While the former is often under the enterprise’s control, the latter is often beyond its control. <br />
For some systems, determining the boundary is a key decision, subject to many possibilities and consequences. This is perhaps less the case for enterprises whose bounds are determined by the extent of organizations, regulations, supply chains or other criteria. Within an established boundary, the '''''holism''''' principle applies: to treat the enterprise as a unified whole, and, in particular, with respect to the '''''interaction''''' of the enterprise with its ''environment''—including stakeholders, other enterprises and systems. From an enterprise IT perspective, an enterprise is a ''system of systems. '' SoC offers a way to focus on the constituent systems in terms of their interconnections to one another to form the enterprise.<br />
Another useful application of SoC is to apply the principle of '''''multiple views''''' to depict the architecture of the enterprise in different ways to address the diverse interests (i.e., ''concerns'') of an enterprise’s various stakeholders. Each ''architecture view'' presents a specific perspective on the enterprise. To be understandable to its audiences (those various stakeholders), each view should follow the conventions of its ''architecture viewpoint'' (ISO/IEC/IEEE 42010 2011). Just as a map should have a legend, each view should have a documented viewpoint providing a prescribed set of conventions for looking at the enterprise through the resulting view. A viewpoint definition serves as a contract between the architect and stakeholders on ''how'' a selected set of concerns are to be addressed. Each viewpoint allows the architect to consider the enterprise in terms of various kinds of elements and relations among them and to present that view to those “concerned” stakeholders. Dominating concerns in enterprise architecture include interoperability, quality of systems and services, operations, managing change, and alignment with the enterprise’s mission, market, and technology. Via the principle of '''''dualism''''', we recognize that some viewpoints are paired, such as with process/data duality. Another pervasive duality in the enterprise is of people/technology in terms of what capabilities are automated and which are performed by people.<br />
In support of enterprise architecture, there are numerous ''enterprise architecture frameworks'' each providing a pre-defined, integrated set of viewpoints to frame typical, recurring concerns (ISO/IEC/IEEE 42010 Users Group 2022). The earliest recorded framework was (Hammer et al. 1986), developed in the mid-1980s in response to growing availability of distributed computing to the enterprise (Rivera 2013). In the late 1980s, US NIST created its Enterprise Architecture Model as a guide for US federal departments to organize their IT offerings (Fong and Goldfine 1989). NIST’s 5-layer model remains influential today. Despite never using the term “enterprise,” Zachman’s information systems architecture has had a major influence on how subsequent frameworks have been organized and depicted using grids or cubes. Later frameworks have evolved in response to emerging concepts, such as the move from client-server to service-oriented applications, as in the OASIS SOA Reference Model and its associated framework. The 1990s saw a proliferation of frameworks for defense enterprises including US DODAF, UK MODAF, NATO’s NAF and led to successors such as OMG’s UAF.<br />
Yet another application of '''''separation of concerns''''' is distinguishing today’s needs versus facilitating future needs; balancing '''''stability/change''''' and highlighting the temporal planning aspect of architecture of the enterprise. In concert with applying SOC, the architect uses the principle of '''''abstraction''''' to “forget” some details of the subject and thus focus on essentials. Just as SoC is a way of taking things apart, '''''abstraction''''' is a way of unifying or putting like things together through generalization. These two principles are perhaps the most central to architecture. SoC and abstraction work together: SoC picks out subjects and abstraction helps architects to focus upon the essentials of each subject. <br />
Returning to the '''''boundary''''' and '''''holism''''' principles, the enterprise architect applies these recursively. As architecting proceeds, the internal details of the enterprise become known in terms of '''''interaction''''' among its parts and other '''''relations'''''. Again, '''''multiple views''''' are used to factor specific '''''relations'''''into distinct views. Typical relations include Causality, Dependency, Client-Server, and Input-Output. <br />
There are a variety of ways to structure the enterprise based upon stakeholder needs, mission or charter, technologies or capabilities already in place. Among these are structuring principles including: <br />
* '''''Modularity''''' (separate and group capabilities into modules by commonalities); <br />
* '''''Network''''' (modules are linked together); <br />
* '''''Encapsulation''''' (separating architecture modules use from how they are implemented); <br />
* '''''Layer Hierarchy''''' (separation through gradual refinement); <br />
* ''''' Regularity''''' (uniformity of interactions, of structure within layer, within network). <br />
* ''''' Similarity/Difference''''' (recognizing the limits of Regularity)<br />
A simple pattern for architecture has been defined (Hofmeister ''et al. '' 2007). Its elements are Analysis, Synthesis and Evaluation. See Figure 1 below. <br />
''Architecture Analysis'' formulates architecturally-significant requirements (ASRs)—those requirements which influence an enterprise’s architecture. Architecture analysis is based on identified concerns and other information based on understanding the enterprise’s environment, known requirements, stakeholder needs and any constraints. ASRs reflect the “design problems” that the architecture must solve. In many cases, negotiations take place to modify incoming needs, requirements and expectations to make solutions possible. The result of this activity takes the form of ASRs, including architecture principles and initial enterprise-wide decisions.<br />
''Architecture Synthesis'' develops candidate solutions in response to the concerns and ASRs. During Synthesis the architect works out the details of solutions to the identified design problems, tradeoff and interactions between them which are likely to generate further design problems. Synthesis elaborates the ASRs, principles and initial decisions into more detailed solution elements. The principle of ''''' EQUIFINALITY''''' reminds us that for many stable situations (i.e., states of the enterprise), there are many ways to reach those states.<br />
''Architecture Evaluation'' validates whether chosen solutions satisfy ASRs or whether rework is needed (ISO/IEC/IEEE 42030 2019).<br />
Applying the principles discussed above is pervasive in enacting the Analysis–Synthesis–Evaluation pattern iteratively. <br />
<br />
[[File:SEBoK EIT Figure 1.png|centre|thumb|1500px|'''Figure 1. A pattern for Architecture.''']] <br />
<br />
While there are many commonalities among EIT, systems and software architectures, Figure 2 addresses the relationships ''between'' them. Viewing an enterprise as a system, the EIT architecture governs the fundamental IT decisions of the enterprise. That enterprise might be extended to “outsiders” such as vendors, suppliers and perhaps customers. Depending upon the enterprise, the ''governs'' relationship may entail very strict rules or loose guidance. <br />
Within the enterprise, the ecosystem of systems, applications and data may be viewed as a system of systems. The EIT Architecture constrains the architectures governing individual systems, applications and data stores within the enterprise, so that these are able to interoperate and otherwise “play nicely” together.<br />
<br />
[[File:EIT Figure 2.png|centre|thumb|1500px|'''Figure 2. Relating Enterprise IT, Systems and Software Architecture.''']] <br />
<br />
===Strategy and Governance===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance] for additional information. ''<br />
<blockquote><br />
[http://eitbokwiki.org/Glossary#eit Enterprise information technology] (EIT) governance is the established process of defining the strategy for the EIT organization and overseeing its execution to achieve enterprise goals. Strategic planning translates the larger enterprise’s goals into EIT goals and defines what EIT must do to achieve those goals. This effort then communicates this hierarchy of goals: EIT goals as well as how they support the enterprise’s goals. EIT governance drives needed changes to achieve those goals, while maintaining agreed levels of operation. Taking into account various perspectives (such as financial, historical, environmental, and future projections), a strategic plan is a roadmap for action and change, both vertically and horizontally, across the EIT organization. The EIT organization’s strategic plans are based on the enterprise’s strategic plans, focusing on EIT’s role in them; EIT governance provides a monitoring and control framework to achieve strategic goals and objectives. Thus, EIT governance is essential for achieving the EIT strategy and goals..<br />
-[http://eitbokwiki.org/Strategy_and_Governance EITBOK wiki]<br />
</blockquote><br />
<br />
The principle of ''''' PARSIMONY''''' applies here, too (see [[Principles of Systems Thinking]]). These principles will be designated in this article with '''''bold italics'''''. For example, the simplest possible measurement and reporting systems are most likely to be used and not corrupted. Similarly, the EIT organizational structure should be straightforward and easy to traverse so that staff can communicate and problem-solve in teams.<br />
In governing the EIT organization to meet its dual goals of satisfying its customers and meeting its budget and schedule commitments, EIT management encounters the difficulty of managing in the face of '''''dualism''''', “ensuring a constant dynamic balance often through a cyclic dominance of one element and then the other”. The most obvious instance of handling ''''' dualism''''' in EIT is the trade-off between budget, project prioritization and features within projects.<br />
===Change===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Change_Initiatives Change Initiatives] for more information. ''<br />
There are two levels of change management discussed in the EITBOK: organizational change management and changes to the IT organization’s assets, whether they be software, hardware, or telecommunications systems.<br />
In the larger sense, the introduction of new systems and services often also requires changes in people’s jobs and in the processes used to accomplish those jobs. Such efforts are intended to increase business value. Such changes require change initiatives because they involve guiding a mixture of stakeholders through the change process. This is one aspect of [http://eitbokwiki.org/Change_Initiatives change management].<br />
Change also occurs when existing systems or services must be updated to meet new needs. Depending on the scope of the proposed changes, a change initiative may be required in this situation, too. At any rate, a change request process must be initiated and tracked to disposition (deferral, rejection, or implementation). Changes also come about as a result of defect reports. In such cases, the defect report must be tracked throughout the report’s life cycle, to disposition (deferral, rejection, or implementation).<br />
These latter types of change management are discussed in detail in the EITBOK’s section on [http://eitbokwiki.org/Operations_and_Support Operations and Support].<br />
===Interoperability of Component Systems===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Interoperability interoperability] for more information. ''<br />
As explained in the [http://eitbokwiki.org/Interoperability#One EITBOK], ''interoperability'' means “the ability of systems (including organizations) to exchange and use exchanged information without knowledge of the characteristics or inner workings of the collaborating systems (or organizations).” This definition is based on an ISO definition: “degree to which two or more systems, products, or components can exchange information and use the information that has been exchanged.” (ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models, 4.2.3.2. ) Note that this definition includes hardware components as well as software systems and the organizations in which they are used.<br />
Because technology changes so rapidly, and organizations themselves are frequently changing, achieving and maintaining interoperability is crucial. It is one of the main reasons that providing IT services is difficult and how it differs from engineering and delivering finished products, whether off-the-shelf products or bespoke systems.<br />
===Security of Systems and Data===<br />
<blockquote><br />
There are only two types of companies: those that have been hacked, and those that will be.<br />
-FBI Director Robert Mueller, October 2012<br />
</blockquote><br />
<br />
<blockquote><br />
There are two kinds of big companies in the United States. There are those who've been hacked by the Chinese and those who don't know that they've been hacked by the Chinese<br />
-FBI Director James Comey, October 2014<br />
</blockquote><br />
''See the EITBOK’s section on [http://eitbokwiki.org/Security security] for additional information. ''<br />
While there are many definitions for security, most include the three dimensions of confidentiality, integrity, and availability (sometimes referred to as the [http://eitbokwiki.org/Glossary#ciatriad CIA triad]). As such, the primary goal of EIT security is to preserve the confidentiality, integrity, and availability of information and information systems. <br />
The principles behind an organization’s [http://eitbokwiki.org/Glossary#isms information security management system] (ISMS) should be to design, implement, and maintain a coherent set of policies, processes, and systems that keep the risks associated with its information assets at a tolerable level, and yet, manage the cost and inconvenience of said risk management. As such, the goals of EIT security are to:<br />
* Always understand the current risk tolerance of the enterprise with respect to information and device security.<br />
* Understand the security threats and potential damages to information, devices, and individuals.<br />
* Create and follow policies and procedures that keep cyberattack risk and damages at or below a tolerable level.<br />
* Effectively and efficiently detect and deal with<br />
[http://eitbokwiki.org/Security#One cyberattack incidents].<br />
Ensuring security in EIT has been made even more pressing and more difficult by the proliferation of mobile devices in enterprises and their ever-increasing use to conduct business. Increasingly, personal devices (Bring Your Own Device – BYOD) are used, accessing both corporate networks and public networks. The cost of [https://www.checkpoint.com/downloads/products/check-point-mobile-security-survey-report2013.pdf mobile security incidents] very easily can outweigh the cost of the mobile device itself. <br />
==Quality of Systems and Services==<br />
The Enterprise ''Information'' Technology organization has, since its origins, had as its primary responsibility the timely provision of information to the larger organization. The information is expected to be not only timely, but also accurate and relevant. While the EIT organization itself may not be responsible for creating the data, it is responsible for the physical and logical validity and [https://simplicable.com/new/data-integrity-vs-data-quality integrity of the data] that is used to construct information. It is for this reason that defining and using appropriate processes is essential to ensure high-quality operation, including the development or acquisition, implementation and integration of new or changed capabilities.<br />
The EITBoK details the quality concepts of<br />
* How to approach measuring [http://eitbokwiki.org/Quality#Measuring_Quality Quality]<br />
* The importance of Quality in [http://eitbokwiki.org/Quality#Requirements_Management Requirements Management]<br />
* Understanding an organization’s [http://eitbokwiki.org/Quality#Quality_Capability Quality Capability]<br />
* The differences between [http://eitbokwiki.org/Quality#QMS_and_QC_vs._QA QMS, QC and QA]<br />
* Cost of Quality in [http://eitbokwiki.org/Quality#Technical_Debt_and_the_Cost_of_Rework Technical Debt and the Cost of Rework]<br />
==Disaster Preparedness==<br />
<br />
As explained in the [http://eitbokwiki.org/Disaster_Preparedness EITBOK], disaster preparedness and [http://eitbokwiki.org/Glossary#dr disaster recovery] (DR) support business-continuity planning and include planning for EIT resiliency, as well as recovery from adversity, so that critical business services affected are restored to a satisfactory working state within an [http://eitbokwiki.org/Glossary#acceptable acceptable] timeframe after an event.<br />
The EITBoK devotes a chapter to how the EIT organization and its parent must plan in advance for how it will provide sufficient organizational resilience to recover from disasters and return to normal operation as rapidly as possible.<br />
It provides the following examples of disasters and service interruptions that could occur and should be considered in prevention and recovery planning:<br />
These are examples of disasters:<br />
* Natural disaster affecting datacenters or EIT service operations (flood, fire, earthquake, wind)<br />
* Security breach resulting in a disaster (destruction of data, admin password changes, virus/malware installation, sabotage)<br />
* Usage error (accidental deletion, unplug/turn off system resulting in corruption)<br />
* Utility failure affecting datacenters (loss of power even after UPS)<br />
* Vendor failure (cloud provider security failure, oil spill)<br />
* Staffing issue (employment dispute/walkout, epidemic)<br />
These are examples of unpreparedness:<br />
* Requiring use of computers or printers when power is out<br />
* Requiring use of Internet when power or connectivity is out<br />
* Single point of knowledge/control for administration access<br />
* Lack of offsite backup storage<br />
* Lack of working restoration from backups<br />
* Lack of failover datacenters in separate locations<br />
* Undocumented or out-of-date documentation for system interfaces<br />
*Requiring use of phones that are out of power<br />
* Lack of designation of leaders in restoration efforts (who is in charge of restoring service and they know they are in charge)<br />
* In general, no cohesive, comprehensive EIT service restoration plan<br />
==Operations and Support of Delivered Systems and Services==<br />
[http://eitbokwiki.org/Operations_and_Support Operations and support activities] focus on maintaining an operation normal state in EIT environments, meaning that systems and processes execute according to expectations, with no surprises to users. This desired normal state requires the careful management of EIT assets and services via Operations, as well as of users via Support.<br />
Normal states can be disrupted either by the expected and planned transition of an asset, or by an unexpected event, be it as large as a disaster or by the discovery of a system defect. In the former case, the Disaster Recovery Plan is executed; in the latter, incident management kicks in when a system halts, or problem management is exercised when an operational system is not functioning as expected. The processes needed to ensure effective application of these complex functions is detailed in the [http://eitbokwiki.org/Operations_and_Support#Guiding_Principles Operations and Support Knowledge Area] within the EITBOK. <br />
ISO/IEC/IEEE 20000 may be used by any organization to develop and manage EIT operations, along with the current version of [https://www.servicenow.com ITIL].<br />
ITIL for many is the tool of choice for the operations and infrastructure side of IT, particularly for IT services. <br />
==Ethics==<br />
See the EITBOK’s section on [http://eitbokwiki.org/Ethics ethics] for additional information.<br />
Both the IEEE and ACM require their members to adhere to Codes of Ethics. See the [https://www.ieee.org/about/corporate/governance/p7-8.html IEEE Code of Ethics] and [https://www.acm.org/code-of-ethics ACM Code of Ethics and Professional Conduct]. Both of these can be downloaded freely. In addition, the IEEE Computer Society and the ACM worked together on the [https://dl.acm.org/action/downloadSupplement?doi=10.1145%2F265684.265699&file=acm-se-code-of-ethics.html Software Engineering Code of Ethics] (also available [https://dl.acm.org/doi/10.1145/265684.265699 here]).<br />
The organization should create an easily accessible Code of Ethics:<br />
* Ethical assertions should be documented and socialized in EIT in the form of a Code of Ethics, tied to the overall business code of ethics, and signed off by all staff so that violations can be cause for reprimand or dismissal.<br />
* Vendors should be held to similar ethical standards.<br />
* Lists of employees who have signed off on the Code of Ethics are maintained by EIT governance.<br />
The EITBOK has identified EIT ethical topics that include:<br />
* Those actions and decisions that may be illegal<br />
* Consideration of the social impact of the work at hand—if it will cause harm<br />
* Alignment of business and EIT strategies and policies to an ethical standard<br />
* Incorporation of the ideals of professionalism<br />
* Adherence to applicable regulatory intent<br />
* Protection for whistle blowers<br />
Areas to specifically highlight:<br />
* Activities that interfere with or corrupt the proper function of computers, applications and systems<br />
* Activities that interfere with digital privacy or intellectual rights of others<br />
* Respect for confidentiality, privacy, permissions, and access rights<br />
* Inappropriate bias (skewing) of analysis and reporting<br />
* Inaction in the face of likely ethics violations<br />
==EIT Roles==<br />
Several roles play a part in accomplishing the EIT organization’s mission. Just as a systems engineer can play several roles in a given project, so might several people in an EIT project combine to fulfill the systems engineering function. <br />
The function of EIT systems engineering is to orchestrate systems development, delivery and operation such that the larger organization achieves favorable outcomes in complex environments. Unlike systems projects that are built for known problems, EIT systems may change in unpredictable ways. A primary concern focuses on how quickly systems adapt to change. This entails a type of resiliency based on skills in establishing options and alternative solutions as well as strategies tailored to the volatility of changing needs and available technologies. It also requires expertise in assuring that systems quality is assured from the start.<br />
Different countries, geographic areas and organizations do not always use the same terminology to reference the functions that the roles contributing to systems engineering perform. The following section will provide information about some major international models for defining EIT skills and capabilities. Generally, though, the necessary roles across the product life cycle include these:<br />
* Business Sponsor/Champion<br />
* Enterprise Architect<br />
* Systems Engineer<br />
* Financial Manager<br />
* Application Architect<br />
* Business Analyst and/or Process Analyst<br />
* Data Analyst and/or Data Architect<br />
* Software Engineer and/or Programmer<br />
* Quality Assurance & Testing<br />
* Network Engineer<br />
* Telecoms Engineer<br />
* Integration Expert <br />
* Transition to Operations Manager<br />
* Release Manager<br />
* Availability Manager<br />
* Capacity Manager<br />
* Change Manager<br />
* Configuration Manager<br />
* EIT Operations Manager<br />
* Incident Management<br />
* Problem Manager<br />
* Service Level Manager<br />
* Database Administrator<br />
* Network Manager<br />
* Product Manager<br />
System engineering activities orchestrate the work of these roles so that they function together, rather than in silos or at cross purposes.<br />
==Examples of Systems Engineering in EIT==<br />
Systems Engineering provides a holistic discipline for integrating and managing the contributions of all roles needed to establish and provide EIT products and services. It ensures that a single perspective does not dominate outcomes; instead, it seeks balance among the many disciplines represented above in creating a consistent product or service that meets the interests and needs of enterprise users (and, perhaps, partners). It boils down to common sense, technical sense, knowing when to ask the right questions, and getting the data to support the answers to those questions. System Engineering achieves this via Systems Engineers. In many instances, though, the SE function is accomplished through Project Management approaches using Integrated Product Teams that include technical experts. Thus, although not specifically calling out a Systems Engineering function, the use of IPTs involved the use of SE practices.<br />
A doctoral dissertation from Purdue University performed a survey and causal analysis of project failures and of accidents(Aloisio, 2018). The results were similar to those found in reviews of IBM consulting projects in the 1990s . The following are examples of Systems Engineering interventions that prevented project failures. Almost all point to the lack of the System Engineering balancing act needed for product delivery.<br />
* A widely used document processing product was undergoing a major upgrade. The new VP of Engineering wanted a project review before committing to a schedule. The review showed that the proposed schedule only considered the development effort and did not give sufficient weight to the voices of the testing and documentation organizations, while the needs of the tech support group had been completely overlooked. By establishing an integrated product management team that included technical expertise, as well as expertise in work breakdown and estimating, a realistic effort was defined and the resulting 9-month schedule was met within 3 weeks.<br />
* A Silicon Valley start-up was depending entirely on an offshore development effort to produce its first product. All senior management was in the U.S. The VP of engineering made monthly visits to the development team. The CEO began to feel uneasy about the team’s ability to deliver on schedule sensing that a lot of finger pointing within the development team itself signaled problems. There was no SE or IPT guiding the project. The VP of Engineering seemed unable to sort things out. A project review showed that the probable delivery date was at least 6 months beyond what the CEO was being told. The project was shut down.<br />
* A major player in Human Resource Management had made commitments to deliver a new product. The project involved more than 100 people across the U.S. The delivery date kept slipping. Project roll-out would involve both installation of software and hardware at client sites, as well as installation and staff training at the large, centrally located Client Services organization. Executive Management needed to decide whether to reorganize this very expensive effort or cancel it. Again, the successful solution depended on establishing an effective cross-functional team (IPT) that necessarily included representatives from the technical teams. The IPT was supported by a newly established Project Management Office (PMO). The PMO integrated the geographically disparate efforts by establishing communication channels, as well as common estimating and scheduling practices. The PMO also instituted monthly critical metrics reports to show the IPT bottlenecks and inefficiencies across the project, from development efforts to Client Services set-up to Payroll technical support.<br />
There are far more examples of the lack of systems engineering practices in EIT projects than in their successful use (unfortunately, this seems also to be true in lots of software projects outside of EIT). Systems Engineering provides a holistic discipline for integrating and managing the contributions of all of the roles needed to provide EIT products and services. It ensures that a single perspective does not dominate outcomes.<br />
==Key External Models of EIT Organizational Capability and Maturity==<br />
Because EIT is critical to businesses globally, considerable effort has gone into establishing universal frameworks for EIT skills, along with definitions of levels of capability of each skill. In addition, at least 2 models have been developed for evaluating the organizational performance of EIT. The effectiveness of systems engineering is key to the effectiveness of the EIT organization.<br />
===IT-CMF: IT-Capability Maturity Framework=== <br />
The IT-CMF had its origin in a quality improvement effort at Intel Labs Europe in Ireland. Its intent, as described at the <br />
[https://cio-wiki.org/wiki/IT_Capability_Maturity_Framework_(IT-CMF) CIO Index website] was to quantify and demonstrate the true value impact of IT. IT-CMF is used to measure, develop, and monitor an organization’s EIT capability maturity. It consists of 35 EIT management capabilities organized into four macro capabilities: managing EIT like a business; managing the EIT budget; managing the EIT capability; and managing EIT for business value. Its 35 critical capabilities (CCs) are [http://eitbokwiki.org/Enterprise_IT_Maturity_Assessment described] as “A defined EIT management domain that helps mobilize and deploy EIT-based resources to effect a desired end, often in combination with other resources and capabilities”. <br />
===CMMI: Capability Maturity Model Integration (US)===<br />
The CMMI had its origin in 1987 in a model requested by the U.S. Department of Defense for determining the capability maturity of contractor software development organizations. This became the Capability Maturity Model (CMM). Since then, it has been expanded into a set of Capability Maturity Models, all based on five levels of demonstrably increasing maturity as measured by organization performance. That set was then integrated and became the CMMI. The CMMI set addresses [https://cmmiinstitute.com/dev Development], [https://cmmiinstitute.com/svc Services], [https://cmmiinstitute.com/sm Supplier Management], [https://cmmiinstitute.com/pm People Management], and [https://cmmiinstitute.com/dm Data Management].<br />
===SFIA: Skills Framework for the information Age (Europe, Canada and US)===<br />
The SFIA Framework has been downloaded and used by organizations and individuals in nearly 180 countries. It can be downloaded for free at [https://www.sfia-online.org]. It identifies 97 professional skills across EIT and supporting areas with seven levels of responsibility, which provide generic levels of responsibility, taking into account reflect experience and competency. These describe the behaviors, values, knowledge, and characteristics that an individual should have in order to be considered competent at a particular level.<br />
===E-CF: European Competency Framework (EU)===<br />
The ECF was the first sector-specific implementation of the European Qualifications Framework (EQF). The European Norm (EN) 16234-1 European e-Competence Framework (e-CF) provides a reference of 41 competences as applied at the Information and Communication Technology (ICT) workplace, using a common European reference for competences, skills, knowledge and proficiency levels. The E-CF Explorer web tool is available [https://ecfexplorer.itprofessionalism.org/ online].<br />
===I Competency Dictionary: EIT skills as Defined by METI/ IPA (Japan)===<br />
The Japanese government’s Information-Technology Promotion Agency (IPA), established by the Ministry of Economy, Trade and Industry (METI) developed the ”I Competency Dictionary” (iCD) to support the IT Engineers Examination. It underlies the METI/IPA Skills Standards for IT Professionals, abbreviated as ITSS, established in 2002. ITSS organizes skills within the information services industry into 11 job categories and 35 specialty fields. In each field, there are seven levels of competence based on individual experience and ability to perform. One appealing feature of ITSS is that this standard allows engineers to draw roadmaps for their own futures and career advancement (Career Path). Approximately 90% of large enterprises and over 60% of SMEs in Japan have introduced or are considering using ITSS. Information in English is available at https://www.ipa.go.jp/english/humandev/forth.html.<br />
===ITIL: Information Technology Infrastructure Library===<br />
According to ITLIlibrary.org, the ITIL Open Guide website, “The Information Technology Infrastructure Library (ITIL) defines the organisational structure and skill requirements of an information technology organisation and a set of standard operational management procedures and practices to allow the organisation to manage an IT operation and associated infrastructure. … The [https://www.itlibrary.org/ “library”] itself continues to evolve. This comprises five distinct areas: <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Strategy ITIL Service Strategy]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Design ITIL Service Design]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Transition ITIL Service Transition]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Operation ITIL Service Operation]; and <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Continual_Service_Improvement ITIL Continual Service Improvement].”<br />
It originally grew out of a British government sponsored effort to regularize IT Service Management (ITSM). <br />
==References==<br />
===Works Cited===<br />
Fong, E.N. and A.H. Goldfine. 1989. ''Information Management Directions: The Integration Challenge. '' National Institute of Standards and Technology (NIST) Special Publication 500-167, September 1989. https://csrc.nist.rip/library/NIST%20SP%20500-167.pdf <br />
<br />
Hammer, M., T.H. Davenport and J. Champy. 1986. ''Dispersion and Interconnection: Approaches to Distributed Systems Architecture'', Cambridge, MA: CSC Index Inc. and Hammer and Company, Inc. (June 1986). Available as: https://www.globalaea.org/general/custom.asp?page=Resources <br />
<br />
Hilliard, R. 2015. “Lessons from the fundamental unity of architecting”. ''Software Engineering in the Systems Context'', editors: Ivar Jacobson and Harold 'Bud' Lawson.<br />
<br />
Hofmeister, C. et al. 2007. “A general model of software architecture design derived from five industrial approaches”. ''The Journal of Systems and Software'' 80(1). <br />
<br />
ISO/IEC 25010:2011 ''Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models'', 4.2.3.2.<br />
<br />
ISO/IEC/IEEE 42010 Users Group. ''Survey of Architecture Frameworks'' Available as: http://www.iso-architecture.org/42010/afs/<br />
<br />
ISO/IEC/IEEE. 2011. ISO/IEC/IEEE 42010:2011, ''Systems and software engineering — Architecture description. ''<br />
<br />
PMI. 2013. ''Software Extension to PMBOK® Guide – Fifth Edition. '' Newtown Square, PA, USA: Project Management Institute (PMI). Available as: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/software-extension-5th-edition.<br />
<br />
Rivera, R. 2013. “The PRISM Architecture Framework – Was it the Very First Enterprise Architecture Framework?” ''Journal of Enterprise Architecture'', November 2013<br />
<br />
Zachman, J. 1987. “A Framework for Information Systems Architecture”. ''IBM Systems Journal'', pp454-470, 1987 <br />
<br />
===Primary References===<br />
IEEE Computer Society. ''Enterprise IT Body of Knowledge''. Available: http://eitbokwiki.org<br />
<br />
=-=Additional References===<br />
IT Capability Maturity Framework (IT-CMF): The Body of Knowledge Guide. 2015. Editors. Martin Curley, Jim Kenneally, Marian Carcary. Van Haren Publishing.<br />
<br />
Lessons from Systems Engineering Failures: Determining Why Systems Fail, The State of Systems Engineering Education, and Building an Evidence-Based Network to Help Systems Engineers Identify and Fix Problems on Complex Projects, Diane Constance Aloisio, December 2018.<br />
<br />
===International Standards Guiding EIT===<br />
ANSI/AIAA. 2012. ''ANSI/AIAA Guide to the Preparation of Operational Concept Documents. '' ANSI/AIAA G-043A-2012e.<br />
<br />
IEEE 2012 Std 828™-2012, ''IEEE Standard for Configuration Management in Systems and Software Engineering. ''<br />
<br />
ISO 10004:2012, Quality management—Customer satisfaction—Guidelines for monitoring and measuring<br />
<br />
ISO 10007:2003, Quality management systems—Guidelines for configuration management<br />
<br />
ISO 18238:2015, Space systems—Closed loop problem solving management<br />
<br />
ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models<br />
<br />
ISO/IEC 16350:2015, Information technology—Systems and software engineering—Application management<br />
<br />
ISO/IEC 19770-1:2012, Information technology—Software asset management—Part 1: Processes and tiered assessment of conformance<br />
<br />
ISO/IEC 20000-1:2011, (IEEE Std 20000-1:2013) Information technology—Service management—Part 1: Service management system requirements<br />
<br />
ISO/IEC 20000–2:2012, Information technology—Service management—Part 2: Guidance on the application of service management systems<br />
<br />
ISO/IEC TR 20000–10:2015, Information technology—Service management—Part 10: Concepts and terminology<br />
<br />
ISO/IEC TR 20000–11:2015, Information technology—Service management—Part 11: Guidance on the relationship between ISO/IEC 20000-1:2011 and related frameworks: ITIL®<br />
<br />
ISO/IEC TR 20000-12—Information technology—IT Service management—Part 12: Guidance on the relationship between ISO/IEC 20000-1:2011 and service management frameworks: CMMI-SVC®<br />
<br />
ISO/IEC/IEEE 14764-2006, Software Engineering—Software Lifecycle Processes—Maintenance<br />
<br />
ISO/IEC 15939:2007, Systems and software engineering—Measurement process<br />
<br />
ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description <br />
<br />
<br />
----<br />
<center>[[ Systems Engineering and Economics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Quality Attributes|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Enterprise_IT&diff=66936
Systems Engineering and Enterprise IT
2023-05-07T03:49:50Z
<p>Mhaas: </p>
<hr />
<div>----<br />
'''''Lead Authors:''''' Chuck Walrad and Richard Hilliard<br />
----<br />
This article forms part of the [[Related Disciplines]] knowledge area (KA). It discusses enterprise IT, building upon the concepts and practices of Systems Engineering presented elsewhere in the SEBOK. Systems Engineering is integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of ''engineered technical systems''. <br />
<br />
== Enterprise IT Introduction==<br />
Although it had its origin in the need to improve success rates in U.S. Government outsourcing of technical systems, Systems Engineering is also integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of [https://www.incose.org/about-systems-engineering/system-and-se-definition/systems-engineering-definition#ENGINEERED_SYSTEM engineered technical systems].<br />
Examples of EIT systems include enterprise resource planning, supply chain management and customer relationship management systems, accounting, finance, inventory and order management, marketing, planning, purchasing, and sales.<br />
In the late 1980s and throughout the 1990s, EIT organizations became increasingly aware that the success rates of IT projects were very low, and that their enterprise customers were increasingly unhappy with their EIT investments. The Standish Group sought to understand what was going on. Their findings were presented in the [https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf Chaos Report] (1994):<br />
The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable but could easily be in the trillions of dollars.<br />
As a result, commercial IT organizations, through the auspicious parallel emergence of the Total Quality Management movement and the increasingly widespread development of application development methodologies (ADM) by IT management consulting firms, recognized the need for the principles of Systems Engineering and cross-functional teams (Integrated Product Teams [https://www.sebokwiki.org/wiki/Integrated_Product_Team_(IPT)_(glossary)]. It should be noted that there is considerable overlap today between what constitutes Systems Engineering and what constitutes [[Project and Portfolio Management|Relationships between Systems Engineering and Project Management]] (see [https://www.pmi.org/learning/library/bridging-gap-program-management-systems-engineering-6213 PMI]). This article does not attempt to resolve this issue. Note that the “[[Related Business Activities|following business management activities]] can be ''supported'' by enterprise systems engineering (ESE) activities” [emphasis added]: <br />
* mission and strategic planning,<br />
* business processes and information management,<br />
* performance management,<br />
* portfolio management,<br />
* resource allocation and budgeting, and<br />
* program and project management.<br />
Note that these same areas have been designated as being supported by Project Management Offices. However, since a key difference between project management and systems engineering has been identified as the requirement that the latter includes technical expertise in the product/system of concern, focus should be on systems engineering and integrated product teams (IPTs). <br />
With IPTs, each product is shepherded from concept through delivery and support to retirement by a cross-functional team that includes representatives from each area of responsibility, such as customer requirements development, design and development, test, configuration management, release engineering, delivery, and support.<br />
As enterprises have come to depend more and more on technology to perform effectively, Enterprise IT organizations have matured, often due to the influence of IT consulting firms that make it their business to keep abreast of best practices.<br />
<br />
== EIT Concepts ==<br />
This knowledge area (KA) discusses enterprise IT, building upon the concepts elucidated in the IEEE/ACM ''[http://eitbokwiki.org EITBOK Guide to the Enterprise Information Technology Body of Knowledge]'' and general concepts of Systems Engineering elsewhere in SEBOK. <br />
An enterprise may be viewed from various perspectives: such as a system or a [[system of systems (SoS)|Enterprise Systems Engineering]]:<br />
* system-like enterprise: enterprises, like other systems, may have a tight coupling, single-executive function; <br />
* system of systems-like enterprise: may be a loosely coupled group of organizations with blurred boundaries and (yet) with (some) shared outcomes.<br />
The choice of perspective may vary with many factors: the enterprise itself, the mission or purpose, or the particular engineering task at hand. We can view an enterprise as a system with inputs and outputs in relation to the outside world, or a system of systems interacting through their individual inputs and outputs. <br />
An enterprise usually involves one (or more) organization(s) but need not be identified with the organization. As the scope of human and organizational participants of the enterprise widen, there may be no single point of control. For example, an ''extended enterprise'' could include a company, its suppliers and customers.<br />
Whatever perspective (system-like, SoS-like, other) is taken there are [[key ingredients|Enterprise Systems Engineering Background]] of any enterprise: capabilities, individual (competencies) and the organizational design. [[Capabilities|Enterprise Capability Management]] can be further categorized: “There are three different kinds of capability: organizational capability, system capability, and operational capability.” These capabilities determine what the enterprise is able to produce which may be external offerings or internal mechanisms. Operational capabilities create services and/or products which in turn produce value as determined by stakeholders. The capabilities of an enterprise are realized through [[Enterprise Systems Engineering Background|various enterprise elements]], including: “hardware, software, personnel, facilities, data, materials, techniques, and even services”. which include “soft” items, like people, processes, principles, policies, practices, organizations, doctrine, theories, and beliefs.<br />
EIT capabilities exist through lifecycles spanning from creation through eventual replacement and disposal. ''Life cycle models'' are schemes to aid in the understanding, design, planning and management of the capability of interest. <br />
“A life cycle for a system generally consists of a series of stages regulated by a set of management decisions which confirm that the system is mature enough to leave one stage and enter another.” Basic life cycle terms and concepts are discussed in [[System Lifecycle Approaches]]. Some typical life cycles are discussed in [[System Lifecycle Models]].<br />
A life cycle-based approach can be deployed across the several levels and used to manage evolution. These levels are:<br />
* the enterprise itself,<br />
* the processes and organizations constituting the enterprise,<br />
* the systems enabling the capabilities, services or products provided. <br />
It is important to distinguish between ''product'' and ''project'' lifecycle models. A product’s life cycle extends from its initial concept approval, through development and distribution, to its retirement. This is the cycle that is managed within an Enterprise IT organization, since EIT must manage the hardware or software product from its introduction, in the case of acquired capabilities, or from its concept approval and development, in the case of capabilities it builds, through its deployment, maintenance and eventual retirement (withdrawal). Each of these stages is usually managed as a project or a series of projects.<br />
However, most discussions of life cycles within software and systems discussions focus on ''project'' life cycles. See, for example, the ''Software Extension to PMBOK Guide'' (PMI 2013).<br />
==System of Systems Context in EIT==<br />
“Enterprise IT” (EIT) is used both to refer to the technology organization/business unit within the enterprise and to the enterprise’s information technology systems. In this article, we use EIT to refer to the technology systems. When referring to the organization, we use the phrase “Enterprise IT organization” or EIT organization. <br />
Enterprise IT organizations are responsible for complex socio-technical systems. Socio-technical systems in a business context (thus, EIT) contain technical elements (software, hardware, networks, storage, databases, etc.) but they also contain essential human components and necessary business processes. As covered in [[Introduction to Systems Engineering Fundamentals]], they exist in an engineered System Context that is a set of system component interrelationships within a real-world environment:<br />
This includes where problems come from and how they are defined, how we identify and select candidate solutions, how to balance technology and human elements in the wider solution context, how to manage the complex organizational systems needed to develop new solutions, and how developed solutions are used, sustained and disposed of. … Systems Engineering should consider the full Engineered System Context so that the necessary understanding can be reached and the right systems engineering decisions can be made. <br />
Socio-technical systems also have the following key characteristics: ''Openness'' in that they strongly interact with their environments, and ''unfinished'' in that they evolve over time.<br />
A complex of EIT systems is essential to the successful functioning of the humans in the enterprise. They rely on EIT’s technology for communication, for paying employees, for people management, for business measurement, and often for managing supply chains. Thus, “EIT needs to be viewed as a strategic partner to all the other functions and business units within an enterprise. This means that the results produced by EIT along with its effectiveness and efficiency are all critically important to the success of the enterprise.” [http://eitbokwiki.org/What_is_the_Enterprise_Perspective%3F]<br />
To accomplish this mission, the EIT organization builds and acquires new systems or system components, integrates them into the mega System of Systems, and maintains the integrity and interoperability of the individual components, but also the integrity of the entire complex of systems. In addition, security and performance levels must be achieved, benchmarked and maintained or improved.<br />
==Major concerns of the EIT Organization==<br />
The [http://eitbokwiki.org ''Enterprise IT Body of Knowledge''] provides a good deal of information about these major concerns, which we will not replicate here. Rather, links to the relevant areas are provided. The EITBOK demonstrates how, in providing technology systems and services to the enterprise, the EIT organization must skillfully manage such concerns as the following.<br />
<br />
===Enterprise Architecture===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Enterprise_Architecture Enterprise Architecture] for additional information. ''<br />
[http://eitbokwiki.org/Glossary#ea ''Enterprise architecture''] (EA) is the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. EA applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their organization's strategies. Enterprise architecture builds upon many of the concepts and practices of [[System Architecture Definition|systems architecture]] and also software architecture [https://www.sebokwiki.org/wiki/System_Architecture_Definition].<br />
This section will discuss Enterprise Architecture from the perspective of key [[Principles of Systems Thinking]], designated in this article with '''''bold italics'''''. There are many commonalities in architecture whether one is architecture systems, software or the enterprise [Unity]. In this article we highlight both commonalities and differences between Enterprise Architecture and Systems Architecture. <br />
Architecture takes place at the juncture of design problems and their solutions. Design problems rarely arrive fully formulated or “hatched” for the architect; much of the architecture effort is to analyze or formulate the problems to be solved. Often this involves negotiation both within the enterprise and with outside stakeholders. Possible solutions are limited by resources and schedule and therefore often must also be negotiated.<br />
A dominant principle of Enterprise Architecture is '''''separation of concerns''''' (SoC). This is due to the complexity of enterprises, with many forces acting upon them; the many technologies and disciplines involved in their creation and day-to-day operations; and due to the diversity of stakeholders involved in the enterprise (see [[EIT Roles]]). <br />
An application of SoC is the '''''boundary''''' principle which is crucial to separate what is “inside” the enterprise from what is “outside”. While the former is often under the enterprise’s control, the latter is often beyond its control. <br />
For some systems, determining the boundary is a key decision, subject to many possibilities and consequences. This is perhaps less the case for enterprises whose bounds are determined by the extent of organizations, regulations, supply chains or other criteria. Within an established boundary, the '''''holism''''' principle applies: to treat the enterprise as a unified whole, and, in particular, with respect to the '''''interaction''''' of the enterprise with its ''environment''—including stakeholders, other enterprises and systems. From an enterprise IT perspective, an enterprise is a ''system of systems. '' SoC offers a way to focus on the constituent systems in terms of their interconnections to one another to form the enterprise.<br />
Another useful application of SoC is to apply the principle of '''''multiple views''''' to depict the architecture of the enterprise in different ways to address the diverse interests (i.e., ''concerns'') of an enterprise’s various stakeholders. Each ''architecture view'' presents a specific perspective on the enterprise. To be understandable to its audiences (those various stakeholders), each view should follow the conventions of its ''architecture viewpoint'' (ISO/IEC/IEEE 42010 2011). Just as a map should have a legend, each view should have a documented viewpoint providing a prescribed set of conventions for looking at the enterprise through the resulting view. A viewpoint definition serves as a contract between the architect and stakeholders on ''how'' a selected set of concerns are to be addressed. Each viewpoint allows the architect to consider the enterprise in terms of various kinds of elements and relations among them and to present that view to those “concerned” stakeholders. Dominating concerns in enterprise architecture include interoperability, quality of systems and services, operations, managing change, and alignment with the enterprise’s mission, market, and technology. Via the principle of '''''dualism''''', we recognize that some viewpoints are paired, such as with process/data duality. Another pervasive duality in the enterprise is of people/technology in terms of what capabilities are automated and which are performed by people.<br />
In support of enterprise architecture, there are numerous ''enterprise architecture frameworks'' each providing a pre-defined, integrated set of viewpoints to frame typical, recurring concerns (ISO/IEC/IEEE 42010 Users Group 2022). The earliest recorded framework was (Hammer et al. 1986), developed in the mid-1980s in response to growing availability of distributed computing to the enterprise (Rivera 2013). In the late 1980s, US NIST created its Enterprise Architecture Model as a guide for US federal departments to organize their IT offerings (Fong and Goldfine 1989). NIST’s 5-layer model remains influential today. Despite never using the term “enterprise,” Zachman’s information systems architecture has had a major influence on how subsequent frameworks have been organized and depicted using grids or cubes. Later frameworks have evolved in response to emerging concepts, such as the move from client-server to service-oriented applications, as in the OASIS SOA Reference Model and its associated framework. The 1990s saw a proliferation of frameworks for defense enterprises including US DODAF, UK MODAF, NATO’s NAF and led to successors such as OMG’s UAF.<br />
Yet another application of '''''separation of concerns''''' is distinguishing today’s needs versus facilitating future needs; balancing '''''stability/change''''' and highlighting the temporal planning aspect of architecture of the enterprise. In concert with applying SOC, the architect uses the principle of '''''abstraction''''' to “forget” some details of the subject and thus focus on essentials. Just as SoC is a way of taking things apart, '''''abstraction''''' is a way of unifying or putting like things together through generalization. These two principles are perhaps the most central to architecture. SoC and abstraction work together: SoC picks out subjects and abstraction helps architects to focus upon the essentials of each subject. <br />
Returning to the '''''boundary''''' and '''''holism''''' principles, the enterprise architect applies these recursively. As architecting proceeds, the internal details of the enterprise become known in terms of '''''interaction''''' among its parts and other '''''relations'''''. Again, '''''multiple views''''' are used to factor specific '''''relations'''''into distinct views. Typical relations include Causality, Dependency, Client-Server, and Input-Output. <br />
There are a variety of ways to structure the enterprise based upon stakeholder needs, mission or charter, technologies or capabilities already in place. Among these are structuring principles including: <br />
* '''''Modularity''''' (separate and group capabilities into modules by commonalities); <br />
* '''''Network''''' (modules are linked together); <br />
* '''''Encapsulation''''' (separating architecture modules use from how they are implemented); <br />
* '''''Layer Hierarchy''''' (separation through gradual refinement); <br />
* ''''' Regularity''''' (uniformity of interactions, of structure within layer, within network). <br />
* ''''' Similarity/Difference''''' (recognizing the limits of Regularity)<br />
A simple pattern for architecture has been defined (Hofmeister ''et al. '' 2007). Its elements are Analysis, Synthesis and Evaluation. See Figure 1 below. <br />
''Architecture Analysis'' formulates architecturally-significant requirements (ASRs)—those requirements which influence an enterprise’s architecture. Architecture analysis is based on identified concerns and other information based on understanding the enterprise’s environment, known requirements, stakeholder needs and any constraints. ASRs reflect the “design problems” that the architecture must solve. In many cases, negotiations take place to modify incoming needs, requirements and expectations to make solutions possible. The result of this activity takes the form of ASRs, including architecture principles and initial enterprise-wide decisions.<br />
''Architecture Synthesis'' develops candidate solutions in response to the concerns and ASRs. During Synthesis the architect works out the details of solutions to the identified design problems, tradeoff and interactions between them which are likely to generate further design problems. Synthesis elaborates the ASRs, principles and initial decisions into more detailed solution elements. The principle of ''''' EQUIFINALITY''''' reminds us that for many stable situations (i.e., states of the enterprise), there are many ways to reach those states.<br />
''Architecture Evaluation'' validates whether chosen solutions satisfy ASRs or whether rework is needed (ISO/IEC/IEEE 42030 2019).<br />
Applying the principles discussed above is pervasive in enacting the Analysis–Synthesis–Evaluation pattern iteratively. <br />
<br />
[[File:SEBoK EIT Figure 1.png|centre|thumb|500px|'''Figure 1. A pattern for Architecture.''']] <br />
<br />
While there are many commonalities among EIT, systems and software architectures, Figure 2 addresses the relationships ''between'' them. Viewing an enterprise as a system, the EIT architecture governs the fundamental IT decisions of the enterprise. That enterprise might be extended to “outsiders” such as vendors, suppliers and perhaps customers. Depending upon the enterprise, the ''governs'' relationship may entail very strict rules or loose guidance. <br />
Within the enterprise, the ecosystem of systems, applications and data may be viewed as a system of systems. The EIT Architecture constrains the architectures governing individual systems, applications and data stores within the enterprise, so that these are able to interoperate and otherwise “play nicely” together.<br />
<br />
[[File:EIT Figure 2.png|centre|thumb|500px|'''Figure 2. Relating Enterprise IT, Systems and Software Architecture.''']] <br />
<br />
===Strategy and Governance===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance] for additional information. ''<br />
<blockquote><br />
[http://eitbokwiki.org/Glossary#eit Enterprise information technology] (EIT) governance is the established process of defining the strategy for the EIT organization and overseeing its execution to achieve enterprise goals. Strategic planning translates the larger enterprise’s goals into EIT goals and defines what EIT must do to achieve those goals. This effort then communicates this hierarchy of goals: EIT goals as well as how they support the enterprise’s goals. EIT governance drives needed changes to achieve those goals, while maintaining agreed levels of operation. Taking into account various perspectives (such as financial, historical, environmental, and future projections), a strategic plan is a roadmap for action and change, both vertically and horizontally, across the EIT organization. The EIT organization’s strategic plans are based on the enterprise’s strategic plans, focusing on EIT’s role in them; EIT governance provides a monitoring and control framework to achieve strategic goals and objectives. Thus, EIT governance is essential for achieving the EIT strategy and goals..<br />
-[http://eitbokwiki.org/Strategy_and_Governance EITBOK wiki]<br />
</blockquote><br />
<br />
The principle of ''''' PARSIMONY''''' applies here, too (see [[Principles of Systems Thinking]]). These principles will be designated in this article with '''''bold italics'''''. For example, the simplest possible measurement and reporting systems are most likely to be used and not corrupted. Similarly, the EIT organizational structure should be straightforward and easy to traverse so that staff can communicate and problem-solve in teams.<br />
In governing the EIT organization to meet its dual goals of satisfying its customers and meeting its budget and schedule commitments, EIT management encounters the difficulty of managing in the face of '''''dualism''''', “ensuring a constant dynamic balance often through a cyclic dominance of one element and then the other”. The most obvious instance of handling ''''' dualism''''' in EIT is the trade-off between budget, project prioritization and features within projects.<br />
===Change===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Change_Initiatives Change Initiatives] for more information. ''<br />
There are two levels of change management discussed in the EITBOK: organizational change management and changes to the IT organization’s assets, whether they be software, hardware, or telecommunications systems.<br />
In the larger sense, the introduction of new systems and services often also requires changes in people’s jobs and in the processes used to accomplish those jobs. Such efforts are intended to increase business value. Such changes require change initiatives because they involve guiding a mixture of stakeholders through the change process. This is one aspect of [http://eitbokwiki.org/Change_Initiatives change management].<br />
Change also occurs when existing systems or services must be updated to meet new needs. Depending on the scope of the proposed changes, a change initiative may be required in this situation, too. At any rate, a change request process must be initiated and tracked to disposition (deferral, rejection, or implementation). Changes also come about as a result of defect reports. In such cases, the defect report must be tracked throughout the report’s life cycle, to disposition (deferral, rejection, or implementation).<br />
These latter types of change management are discussed in detail in the EITBOK’s section on [http://eitbokwiki.org/Operations_and_Support Operations and Support].<br />
===Interoperability of Component Systems===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Interoperability interoperability] for more information. ''<br />
As explained in the [http://eitbokwiki.org/Interoperability#One EITBOK], ''interoperability'' means “the ability of systems (including organizations) to exchange and use exchanged information without knowledge of the characteristics or inner workings of the collaborating systems (or organizations).” This definition is based on an ISO definition: “degree to which two or more systems, products, or components can exchange information and use the information that has been exchanged.” (ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models, 4.2.3.2. ) Note that this definition includes hardware components as well as software systems and the organizations in which they are used.<br />
Because technology changes so rapidly, and organizations themselves are frequently changing, achieving and maintaining interoperability is crucial. It is one of the main reasons that providing IT services is difficult and how it differs from engineering and delivering finished products, whether off-the-shelf products or bespoke systems.<br />
===Security of Systems and Data===<br />
<blockquote><br />
There are only two types of companies: those that have been hacked, and those that will be.<br />
-FBI Director Robert Mueller, October 2012<br />
</blockquote><br />
<br />
<blockquote><br />
There are two kinds of big companies in the United States. There are those who've been hacked by the Chinese and those who don't know that they've been hacked by the Chinese<br />
-FBI Director James Comey, October 2014<br />
</blockquote><br />
''See the EITBOK’s section on [http://eitbokwiki.org/Security security] for additional information. ''<br />
While there are many definitions for security, most include the three dimensions of confidentiality, integrity, and availability (sometimes referred to as the [http://eitbokwiki.org/Glossary#ciatriad CIA triad]). As such, the primary goal of EIT security is to preserve the confidentiality, integrity, and availability of information and information systems. <br />
The principles behind an organization’s [http://eitbokwiki.org/Glossary#isms information security management system] (ISMS) should be to design, implement, and maintain a coherent set of policies, processes, and systems that keep the risks associated with its information assets at a tolerable level, and yet, manage the cost and inconvenience of said risk management. As such, the goals of EIT security are to:<br />
* Always understand the current risk tolerance of the enterprise with respect to information and device security.<br />
* Understand the security threats and potential damages to information, devices, and individuals.<br />
* Create and follow policies and procedures that keep cyberattack risk and damages at or below a tolerable level.<br />
* Effectively and efficiently detect and deal with<br />
[http://eitbokwiki.org/Security#One cyberattack incidents].<br />
Ensuring security in EIT has been made even more pressing and more difficult by the proliferation of mobile devices in enterprises and their ever-increasing use to conduct business. Increasingly, personal devices (Bring Your Own Device – BYOD) are used, accessing both corporate networks and public networks. The cost of [https://www.checkpoint.com/downloads/products/check-point-mobile-security-survey-report2013.pdf mobile security incidents] very easily can outweigh the cost of the mobile device itself. <br />
==Quality of Systems and Services==<br />
The Enterprise ''Information'' Technology organization has, since its origins, had as its primary responsibility the timely provision of information to the larger organization. The information is expected to be not only timely, but also accurate and relevant. While the EIT organization itself may not be responsible for creating the data, it is responsible for the physical and logical validity and [https://simplicable.com/new/data-integrity-vs-data-quality integrity of the data] that is used to construct information. It is for this reason that defining and using appropriate processes is essential to ensure high-quality operation, including the development or acquisition, implementation and integration of new or changed capabilities.<br />
The EITBoK details the quality concepts of<br />
* How to approach measuring [http://eitbokwiki.org/Quality#Measuring_Quality Quality]<br />
* The importance of Quality in [http://eitbokwiki.org/Quality#Requirements_Management Requirements Management]<br />
* Understanding an organization’s [http://eitbokwiki.org/Quality#Quality_Capability Quality Capability]<br />
* The differences between [http://eitbokwiki.org/Quality#QMS_and_QC_vs._QA QMS, QC and QA]<br />
* Cost of Quality in [http://eitbokwiki.org/Quality#Technical_Debt_and_the_Cost_of_Rework Technical Debt and the Cost of Rework]<br />
==Disaster Preparedness==<br />
<br />
As explained in the [http://eitbokwiki.org/Disaster_Preparedness EITBOK], disaster preparedness and [http://eitbokwiki.org/Glossary#dr disaster recovery] (DR) support business-continuity planning and include planning for EIT resiliency, as well as recovery from adversity, so that critical business services affected are restored to a satisfactory working state within an [http://eitbokwiki.org/Glossary#acceptable acceptable] timeframe after an event.<br />
The EITBoK devotes a chapter to how the EIT organization and its parent must plan in advance for how it will provide sufficient organizational resilience to recover from disasters and return to normal operation as rapidly as possible.<br />
It provides the following examples of disasters and service interruptions that could occur and should be considered in prevention and recovery planning:<br />
These are examples of disasters:<br />
* Natural disaster affecting datacenters or EIT service operations (flood, fire, earthquake, wind)<br />
* Security breach resulting in a disaster (destruction of data, admin password changes, virus/malware installation, sabotage)<br />
* Usage error (accidental deletion, unplug/turn off system resulting in corruption)<br />
* Utility failure affecting datacenters (loss of power even after UPS)<br />
* Vendor failure (cloud provider security failure, oil spill)<br />
* Staffing issue (employment dispute/walkout, epidemic)<br />
These are examples of unpreparedness:<br />
* Requiring use of computers or printers when power is out<br />
* Requiring use of Internet when power or connectivity is out<br />
* Single point of knowledge/control for administration access<br />
* Lack of offsite backup storage<br />
* Lack of working restoration from backups<br />
* Lack of failover datacenters in separate locations<br />
* Undocumented or out-of-date documentation for system interfaces<br />
*Requiring use of phones that are out of power<br />
* Lack of designation of leaders in restoration efforts (who is in charge of restoring service and they know they are in charge)<br />
* In general, no cohesive, comprehensive EIT service restoration plan<br />
==Operations and Support of Delivered Systems and Services==<br />
[http://eitbokwiki.org/Operations_and_Support Operations and support activities] focus on maintaining an operation normal state in EIT environments, meaning that systems and processes execute according to expectations, with no surprises to users. This desired normal state requires the careful management of EIT assets and services via Operations, as well as of users via Support.<br />
Normal states can be disrupted either by the expected and planned transition of an asset, or by an unexpected event, be it as large as a disaster or by the discovery of a system defect. In the former case, the Disaster Recovery Plan is executed; in the latter, incident management kicks in when a system halts, or problem management is exercised when an operational system is not functioning as expected. The processes needed to ensure effective application of these complex functions is detailed in the [http://eitbokwiki.org/Operations_and_Support#Guiding_Principles Operations and Support Knowledge Area] within the EITBOK. <br />
ISO/IEC/IEEE 20000 may be used by any organization to develop and manage EIT operations, along with the current version of [https://www.servicenow.com ITIL].<br />
ITIL for many is the tool of choice for the operations and infrastructure side of IT, particularly for IT services. <br />
==Ethics==<br />
See the EITBOK’s section on [http://eitbokwiki.org/Ethics ethics] for additional information.<br />
Both the IEEE and ACM require their members to adhere to Codes of Ethics. See the [https://www.ieee.org/about/corporate/governance/p7-8.html IEEE Code of Ethics] and [https://www.acm.org/code-of-ethics ACM Code of Ethics and Professional Conduct]. Both of these can be downloaded freely. In addition, the IEEE Computer Society and the ACM worked together on the [https://dl.acm.org/action/downloadSupplement?doi=10.1145%2F265684.265699&file=acm-se-code-of-ethics.html Software Engineering Code of Ethics] (also available [https://dl.acm.org/doi/10.1145/265684.265699 here]).<br />
The organization should create an easily accessible Code of Ethics:<br />
* Ethical assertions should be documented and socialized in EIT in the form of a Code of Ethics, tied to the overall business code of ethics, and signed off by all staff so that violations can be cause for reprimand or dismissal.<br />
* Vendors should be held to similar ethical standards.<br />
* Lists of employees who have signed off on the Code of Ethics are maintained by EIT governance.<br />
The EITBOK has identified EIT ethical topics that include:<br />
* Those actions and decisions that may be illegal<br />
* Consideration of the social impact of the work at hand—if it will cause harm<br />
* Alignment of business and EIT strategies and policies to an ethical standard<br />
* Incorporation of the ideals of professionalism<br />
* Adherence to applicable regulatory intent<br />
* Protection for whistle blowers<br />
Areas to specifically highlight:<br />
* Activities that interfere with or corrupt the proper function of computers, applications and systems<br />
* Activities that interfere with digital privacy or intellectual rights of others<br />
* Respect for confidentiality, privacy, permissions, and access rights<br />
* Inappropriate bias (skewing) of analysis and reporting<br />
* Inaction in the face of likely ethics violations<br />
==EIT Roles==<br />
Several roles play a part in accomplishing the EIT organization’s mission. Just as a systems engineer can play several roles in a given project, so might several people in an EIT project combine to fulfill the systems engineering function. <br />
The function of EIT systems engineering is to orchestrate systems development, delivery and operation such that the larger organization achieves favorable outcomes in complex environments. Unlike systems projects that are built for known problems, EIT systems may change in unpredictable ways. A primary concern focuses on how quickly systems adapt to change. This entails a type of resiliency based on skills in establishing options and alternative solutions as well as strategies tailored to the volatility of changing needs and available technologies. It also requires expertise in assuring that systems quality is assured from the start.<br />
Different countries, geographic areas and organizations do not always use the same terminology to reference the functions that the roles contributing to systems engineering perform. The following section will provide information about some major international models for defining EIT skills and capabilities. Generally, though, the necessary roles across the product life cycle include these:<br />
* Business Sponsor/Champion<br />
* Enterprise Architect<br />
* Systems Engineer<br />
* Financial Manager<br />
* Application Architect<br />
* Business Analyst and/or Process Analyst<br />
* Data Analyst and/or Data Architect<br />
* Software Engineer and/or Programmer<br />
* Quality Assurance & Testing<br />
* Network Engineer<br />
* Telecoms Engineer<br />
* Integration Expert <br />
* Transition to Operations Manager<br />
* Release Manager<br />
* Availability Manager<br />
* Capacity Manager<br />
* Change Manager<br />
* Configuration Manager<br />
* EIT Operations Manager<br />
* Incident Management<br />
* Problem Manager<br />
* Service Level Manager<br />
* Database Administrator<br />
* Network Manager<br />
* Product Manager<br />
System engineering activities orchestrate the work of these roles so that they function together, rather than in silos or at cross purposes.<br />
==Examples of Systems Engineering in EIT==<br />
Systems Engineering provides a holistic discipline for integrating and managing the contributions of all roles needed to establish and provide EIT products and services. It ensures that a single perspective does not dominate outcomes; instead, it seeks balance among the many disciplines represented above in creating a consistent product or service that meets the interests and needs of enterprise users (and, perhaps, partners). It boils down to common sense, technical sense, knowing when to ask the right questions, and getting the data to support the answers to those questions. System Engineering achieves this via Systems Engineers. In many instances, though, the SE function is accomplished through Project Management approaches using Integrated Product Teams that include technical experts. Thus, although not specifically calling out a Systems Engineering function, the use of IPTs involved the use of SE practices.<br />
A doctoral dissertation from Purdue University performed a survey and causal analysis of project failures and of accidents(Aloisio, 2018). The results were similar to those found in reviews of IBM consulting projects in the 1990s . The following are examples of Systems Engineering interventions that prevented project failures. Almost all point to the lack of the System Engineering balancing act needed for product delivery.<br />
* A widely used document processing product was undergoing a major upgrade. The new VP of Engineering wanted a project review before committing to a schedule. The review showed that the proposed schedule only considered the development effort and did not give sufficient weight to the voices of the testing and documentation organizations, while the needs of the tech support group had been completely overlooked. By establishing an integrated product management team that included technical expertise, as well as expertise in work breakdown and estimating, a realistic effort was defined and the resulting 9-month schedule was met within 3 weeks.<br />
* A Silicon Valley start-up was depending entirely on an offshore development effort to produce its first product. All senior management was in the U.S. The VP of engineering made monthly visits to the development team. The CEO began to feel uneasy about the team’s ability to deliver on schedule sensing that a lot of finger pointing within the development team itself signaled problems. There was no SE or IPT guiding the project. The VP of Engineering seemed unable to sort things out. A project review showed that the probable delivery date was at least 6 months beyond what the CEO was being told. The project was shut down.<br />
* A major player in Human Resource Management had made commitments to deliver a new product. The project involved more than 100 people across the U.S. The delivery date kept slipping. Project roll-out would involve both installation of software and hardware at client sites, as well as installation and staff training at the large, centrally located Client Services organization. Executive Management needed to decide whether to reorganize this very expensive effort or cancel it. Again, the successful solution depended on establishing an effective cross-functional team (IPT) that necessarily included representatives from the technical teams. The IPT was supported by a newly established Project Management Office (PMO). The PMO integrated the geographically disparate efforts by establishing communication channels, as well as common estimating and scheduling practices. The PMO also instituted monthly critical metrics reports to show the IPT bottlenecks and inefficiencies across the project, from development efforts to Client Services set-up to Payroll technical support.<br />
There are far more examples of the lack of systems engineering practices in EIT projects than in their successful use (unfortunately, this seems also to be true in lots of software projects outside of EIT). Systems Engineering provides a holistic discipline for integrating and managing the contributions of all of the roles needed to provide EIT products and services. It ensures that a single perspective does not dominate outcomes.<br />
==Key External Models of EIT Organizational Capability and Maturity==<br />
Because EIT is critical to businesses globally, considerable effort has gone into establishing universal frameworks for EIT skills, along with definitions of levels of capability of each skill. In addition, at least 2 models have been developed for evaluating the organizational performance of EIT. The effectiveness of systems engineering is key to the effectiveness of the EIT organization.<br />
===IT-CMF: IT-Capability Maturity Framework=== <br />
The IT-CMF had its origin in a quality improvement effort at Intel Labs Europe in Ireland. Its intent, as described at the <br />
[https://cio-wiki.org/wiki/IT_Capability_Maturity_Framework_(IT-CMF) CIO Index website] was to quantify and demonstrate the true value impact of IT. IT-CMF is used to measure, develop, and monitor an organization’s EIT capability maturity. It consists of 35 EIT management capabilities organized into four macro capabilities: managing EIT like a business; managing the EIT budget; managing the EIT capability; and managing EIT for business value. Its 35 critical capabilities (CCs) are [http://eitbokwiki.org/Enterprise_IT_Maturity_Assessment described] as “A defined EIT management domain that helps mobilize and deploy EIT-based resources to effect a desired end, often in combination with other resources and capabilities”. <br />
===CMMI: Capability Maturity Model Integration (US)===<br />
The CMMI had its origin in 1987 in a model requested by the U.S. Department of Defense for determining the capability maturity of contractor software development organizations. This became the Capability Maturity Model (CMM). Since then, it has been expanded into a set of Capability Maturity Models, all based on five levels of demonstrably increasing maturity as measured by organization performance. That set was then integrated and became the CMMI. The CMMI set addresses [https://cmmiinstitute.com/dev Development], [https://cmmiinstitute.com/svc Services], [https://cmmiinstitute.com/sm Supplier Management], [https://cmmiinstitute.com/pm People Management], and [https://cmmiinstitute.com/dm Data Management].<br />
===SFIA: Skills Framework for the information Age (Europe, Canada and US)===<br />
The SFIA Framework has been downloaded and used by organizations and individuals in nearly 180 countries. It can be downloaded for free at [https://www.sfia-online.org]. It identifies 97 professional skills across EIT and supporting areas with seven levels of responsibility, which provide generic levels of responsibility, taking into account reflect experience and competency. These describe the behaviors, values, knowledge, and characteristics that an individual should have in order to be considered competent at a particular level.<br />
===E-CF: European Competency Framework (EU)===<br />
The ECF was the first sector-specific implementation of the European Qualifications Framework (EQF). The European Norm (EN) 16234-1 European e-Competence Framework (e-CF) provides a reference of 41 competences as applied at the Information and Communication Technology (ICT) workplace, using a common European reference for competences, skills, knowledge and proficiency levels. The E-CF Explorer web tool is available [https://ecfexplorer.itprofessionalism.org/ online].<br />
===I Competency Dictionary: EIT skills as Defined by METI/ IPA (Japan)===<br />
The Japanese government’s Information-Technology Promotion Agency (IPA), established by the Ministry of Economy, Trade and Industry (METI) developed the ”I Competency Dictionary” (iCD) to support the IT Engineers Examination. It underlies the METI/IPA Skills Standards for IT Professionals, abbreviated as ITSS, established in 2002. ITSS organizes skills within the information services industry into 11 job categories and 35 specialty fields. In each field, there are seven levels of competence based on individual experience and ability to perform. One appealing feature of ITSS is that this standard allows engineers to draw roadmaps for their own futures and career advancement (Career Path). Approximately 90% of large enterprises and over 60% of SMEs in Japan have introduced or are considering using ITSS. Information in English is available at https://www.ipa.go.jp/english/humandev/forth.html.<br />
===ITIL: Information Technology Infrastructure Library===<br />
According to ITLIlibrary.org, the ITIL Open Guide website, “The Information Technology Infrastructure Library (ITIL) defines the organisational structure and skill requirements of an information technology organisation and a set of standard operational management procedures and practices to allow the organisation to manage an IT operation and associated infrastructure. … The [https://www.itlibrary.org/ “library”] itself continues to evolve. This comprises five distinct areas: <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Strategy ITIL Service Strategy]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Design ITIL Service Design]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Transition ITIL Service Transition]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Operation ITIL Service Operation]; and <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Continual_Service_Improvement ITIL Continual Service Improvement].”<br />
It originally grew out of a British government sponsored effort to regularize IT Service Management (ITSM). <br />
==References==<br />
===Works Cited===<br />
Fong, E.N. and A.H. Goldfine. 1989. ''Information Management Directions: The Integration Challenge. '' National Institute of Standards and Technology (NIST) Special Publication 500-167, September 1989. https://csrc.nist.rip/library/NIST%20SP%20500-167.pdf <br />
<br />
Hammer, M., T.H. Davenport and J. Champy. 1986. ''Dispersion and Interconnection: Approaches to Distributed Systems Architecture'', Cambridge, MA: CSC Index Inc. and Hammer and Company, Inc. (June 1986). Available as: https://www.globalaea.org/general/custom.asp?page=Resources <br />
<br />
Hilliard, R. 2015. “Lessons from the fundamental unity of architecting”. ''Software Engineering in the Systems Context'', editors: Ivar Jacobson and Harold 'Bud' Lawson.<br />
<br />
Hofmeister, C. et al. 2007. “A general model of software architecture design derived from five industrial approaches”. ''The Journal of Systems and Software'' 80(1). <br />
<br />
ISO/IEC 25010:2011 ''Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models'', 4.2.3.2.<br />
<br />
ISO/IEC/IEEE 42010 Users Group. ''Survey of Architecture Frameworks'' Available as: http://www.iso-architecture.org/42010/afs/<br />
<br />
ISO/IEC/IEEE. 2011. ISO/IEC/IEEE 42010:2011, ''Systems and software engineering — Architecture description. ''<br />
<br />
PMI. 2013. ''Software Extension to PMBOK® Guide – Fifth Edition. '' Newtown Square, PA, USA: Project Management Institute (PMI). Available as: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/software-extension-5th-edition.<br />
<br />
Rivera, R. 2013. “The PRISM Architecture Framework – Was it the Very First Enterprise Architecture Framework?” ''Journal of Enterprise Architecture'', November 2013<br />
<br />
Zachman, J. 1987. “A Framework for Information Systems Architecture”. ''IBM Systems Journal'', pp454-470, 1987 <br />
<br />
===Primary References===<br />
IEEE Computer Society. ''Enterprise IT Body of Knowledge''. Available: http://eitbokwiki.org<br />
<br />
=-=Additional References===<br />
IT Capability Maturity Framework (IT-CMF): The Body of Knowledge Guide. 2015. Editors. Martin Curley, Jim Kenneally, Marian Carcary. Van Haren Publishing.<br />
<br />
Lessons from Systems Engineering Failures: Determining Why Systems Fail, The State of Systems Engineering Education, and Building an Evidence-Based Network to Help Systems Engineers Identify and Fix Problems on Complex Projects, Diane Constance Aloisio, December 2018.<br />
<br />
===International Standards Guiding EIT===<br />
ANSI/AIAA. 2012. ''ANSI/AIAA Guide to the Preparation of Operational Concept Documents. '' ANSI/AIAA G-043A-2012e.<br />
<br />
IEEE 2012 Std 828™-2012, ''IEEE Standard for Configuration Management in Systems and Software Engineering. ''<br />
<br />
ISO 10004:2012, Quality management—Customer satisfaction—Guidelines for monitoring and measuring<br />
<br />
ISO 10007:2003, Quality management systems—Guidelines for configuration management<br />
<br />
ISO 18238:2015, Space systems—Closed loop problem solving management<br />
<br />
ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models<br />
<br />
ISO/IEC 16350:2015, Information technology—Systems and software engineering—Application management<br />
<br />
ISO/IEC 19770-1:2012, Information technology—Software asset management—Part 1: Processes and tiered assessment of conformance<br />
<br />
ISO/IEC 20000-1:2011, (IEEE Std 20000-1:2013) Information technology—Service management—Part 1: Service management system requirements<br />
<br />
ISO/IEC 20000–2:2012, Information technology—Service management—Part 2: Guidance on the application of service management systems<br />
<br />
ISO/IEC TR 20000–10:2015, Information technology—Service management—Part 10: Concepts and terminology<br />
<br />
ISO/IEC TR 20000–11:2015, Information technology—Service management—Part 11: Guidance on the relationship between ISO/IEC 20000-1:2011 and related frameworks: ITIL®<br />
<br />
ISO/IEC TR 20000-12—Information technology—IT Service management—Part 12: Guidance on the relationship between ISO/IEC 20000-1:2011 and service management frameworks: CMMI-SVC®<br />
<br />
ISO/IEC/IEEE 14764-2006, Software Engineering—Software Lifecycle Processes—Maintenance<br />
<br />
ISO/IEC 15939:2007, Systems and software engineering—Measurement process<br />
<br />
ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description <br />
<br />
<br />
----<br />
<center>[[ Systems Engineering and Economics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Quality Attributes|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Enterprise_IT&diff=66935
Systems Engineering and Enterprise IT
2023-05-07T03:48:04Z
<p>Mhaas: Added figures.</p>
<hr />
<div>----<br />
'''''Lead Authors:''''' Chuck Walrad and Richard Hilliard<br />
----<br />
This article forms part of the [[Related Disciplines]] knowledge area (KA). It discusses enterprise IT, building upon the concepts and practices of Systems Engineering presented elsewhere in the SEBOK. Systems Engineering is integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of ''engineered technical systems''. <br />
<br />
== Enterprise IT Introduction==<br />
Although it had its origin in the need to improve success rates in U.S. Government outsourcing of technical systems, Systems Engineering is also integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of [https://www.incose.org/about-systems-engineering/system-and-se-definition/systems-engineering-definition#ENGINEERED_SYSTEM engineered technical systems].<br />
Examples of EIT systems include enterprise resource planning, supply chain management and customer relationship management systems, accounting, finance, inventory and order management, marketing, planning, purchasing, and sales.<br />
In the late 1980s and throughout the 1990s, EIT organizations became increasingly aware that the success rates of IT projects were very low, and that their enterprise customers were increasingly unhappy with their EIT investments. The Standish Group sought to understand what was going on. Their findings were presented in the [https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf Chaos Report] (1994):<br />
The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable but could easily be in the trillions of dollars.<br />
As a result, commercial IT organizations, through the auspicious parallel emergence of the Total Quality Management movement and the increasingly widespread development of application development methodologies (ADM) by IT management consulting firms, recognized the need for the principles of Systems Engineering and cross-functional teams (Integrated Product Teams [https://www.sebokwiki.org/wiki/Integrated_Product_Team_(IPT)_(glossary)]. It should be noted that there is considerable overlap today between what constitutes Systems Engineering and what constitutes [[Project and Portfolio Management|Relationships between Systems Engineering and Project Management]] (see [https://www.pmi.org/learning/library/bridging-gap-program-management-systems-engineering-6213 PMI]). This article does not attempt to resolve this issue. Note that the “[[Related Business Activities|following business management activities]] can be ''supported'' by enterprise systems engineering (ESE) activities” [emphasis added]: <br />
* mission and strategic planning,<br />
* business processes and information management,<br />
* performance management,<br />
* portfolio management,<br />
* resource allocation and budgeting, and<br />
* program and project management.<br />
Note that these same areas have been designated as being supported by Project Management Offices. However, since a key difference between project management and systems engineering has been identified as the requirement that the latter includes technical expertise in the product/system of concern, focus should be on systems engineering and integrated product teams (IPTs). <br />
With IPTs, each product is shepherded from concept through delivery and support to retirement by a cross-functional team that includes representatives from each area of responsibility, such as customer requirements development, design and development, test, configuration management, release engineering, delivery, and support.<br />
As enterprises have come to depend more and more on technology to perform effectively, Enterprise IT organizations have matured, often due to the influence of IT consulting firms that make it their business to keep abreast of best practices.<br />
<br />
== EIT Concepts ==<br />
This knowledge area (KA) discusses enterprise IT, building upon the concepts elucidated in the IEEE/ACM ''[http://eitbokwiki.org EITBOK Guide to the Enterprise Information Technology Body of Knowledge]'' and general concepts of Systems Engineering elsewhere in SEBOK. <br />
An enterprise may be viewed from various perspectives: such as a system or a [[system of systems (SoS)|Enterprise Systems Engineering]]:<br />
* system-like enterprise: enterprises, like other systems, may have a tight coupling, single-executive function; <br />
* system of systems-like enterprise: may be a loosely coupled group of organizations with blurred boundaries and (yet) with (some) shared outcomes.<br />
The choice of perspective may vary with many factors: the enterprise itself, the mission or purpose, or the particular engineering task at hand. We can view an enterprise as a system with inputs and outputs in relation to the outside world, or a system of systems interacting through their individual inputs and outputs. <br />
An enterprise usually involves one (or more) organization(s) but need not be identified with the organization. As the scope of human and organizational participants of the enterprise widen, there may be no single point of control. For example, an ''extended enterprise'' could include a company, its suppliers and customers.<br />
Whatever perspective (system-like, SoS-like, other) is taken there are [[key ingredients|Enterprise Systems Engineering Background]] of any enterprise: capabilities, individual (competencies) and the organizational design. [[Capabilities|Enterprise Capability Management]] can be further categorized: “There are three different kinds of capability: organizational capability, system capability, and operational capability.” These capabilities determine what the enterprise is able to produce which may be external offerings or internal mechanisms. Operational capabilities create services and/or products which in turn produce value as determined by stakeholders. The capabilities of an enterprise are realized through [[Enterprise Systems Engineering Background|various enterprise elements]], including: “hardware, software, personnel, facilities, data, materials, techniques, and even services”. which include “soft” items, like people, processes, principles, policies, practices, organizations, doctrine, theories, and beliefs.<br />
EIT capabilities exist through lifecycles spanning from creation through eventual replacement and disposal. ''Life cycle models'' are schemes to aid in the understanding, design, planning and management of the capability of interest. <br />
“A life cycle for a system generally consists of a series of stages regulated by a set of management decisions which confirm that the system is mature enough to leave one stage and enter another.” Basic life cycle terms and concepts are discussed in [[System Lifecycle Approaches]]. Some typical life cycles are discussed in [[System Lifecycle Models]].<br />
A life cycle-based approach can be deployed across the several levels and used to manage evolution. These levels are:<br />
* the enterprise itself,<br />
* the processes and organizations constituting the enterprise,<br />
* the systems enabling the capabilities, services or products provided. <br />
It is important to distinguish between ''product'' and ''project'' lifecycle models. A product’s life cycle extends from its initial concept approval, through development and distribution, to its retirement. This is the cycle that is managed within an Enterprise IT organization, since EIT must manage the hardware or software product from its introduction, in the case of acquired capabilities, or from its concept approval and development, in the case of capabilities it builds, through its deployment, maintenance and eventual retirement (withdrawal). Each of these stages is usually managed as a project or a series of projects.<br />
However, most discussions of life cycles within software and systems discussions focus on ''project'' life cycles. See, for example, the ''Software Extension to PMBOK Guide'' (PMI 2013).<br />
==System of Systems Context in EIT==<br />
“Enterprise IT” (EIT) is used both to refer to the technology organization/business unit within the enterprise and to the enterprise’s information technology systems. In this article, we use EIT to refer to the technology systems. When referring to the organization, we use the phrase “Enterprise IT organization” or EIT organization. <br />
Enterprise IT organizations are responsible for complex socio-technical systems. Socio-technical systems in a business context (thus, EIT) contain technical elements (software, hardware, networks, storage, databases, etc.) but they also contain essential human components and necessary business processes. As covered in [[Introduction to Systems Engineering Fundamentals]], they exist in an engineered System Context that is a set of system component interrelationships within a real-world environment:<br />
This includes where problems come from and how they are defined, how we identify and select candidate solutions, how to balance technology and human elements in the wider solution context, how to manage the complex organizational systems needed to develop new solutions, and how developed solutions are used, sustained and disposed of. … Systems Engineering should consider the full Engineered System Context so that the necessary understanding can be reached and the right systems engineering decisions can be made. <br />
Socio-technical systems also have the following key characteristics: ''Openness'' in that they strongly interact with their environments, and ''unfinished'' in that they evolve over time.<br />
A complex of EIT systems is essential to the successful functioning of the humans in the enterprise. They rely on EIT’s technology for communication, for paying employees, for people management, for business measurement, and often for managing supply chains. Thus, “EIT needs to be viewed as a strategic partner to all the other functions and business units within an enterprise. This means that the results produced by EIT along with its effectiveness and efficiency are all critically important to the success of the enterprise.” [http://eitbokwiki.org/What_is_the_Enterprise_Perspective%3F]<br />
To accomplish this mission, the EIT organization builds and acquires new systems or system components, integrates them into the mega System of Systems, and maintains the integrity and interoperability of the individual components, but also the integrity of the entire complex of systems. In addition, security and performance levels must be achieved, benchmarked and maintained or improved.<br />
==Major concerns of the EIT Organization==<br />
The [http://eitbokwiki.org ''Enterprise IT Body of Knowledge''] provides a good deal of information about these major concerns, which we will not replicate here. Rather, links to the relevant areas are provided. The EITBOK demonstrates how, in providing technology systems and services to the enterprise, the EIT organization must skillfully manage such concerns as the following.<br />
<br />
===Enterprise Architecture===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Enterprise_Architecture Enterprise Architecture] for additional information. ''<br />
[http://eitbokwiki.org/Glossary#ea ''Enterprise architecture''] (EA) is the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. EA applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their organization's strategies. Enterprise architecture builds upon many of the concepts and practices of [[System Architecture Definition|systems architecture]] and also software architecture [https://www.sebokwiki.org/wiki/System_Architecture_Definition].<br />
This section will discuss Enterprise Architecture from the perspective of key [[Principles of Systems Thinking]], designated in this article with '''''bold italics'''''. There are many commonalities in architecture whether one is architecture systems, software or the enterprise [Unity]. In this article we highlight both commonalities and differences between Enterprise Architecture and Systems Architecture. <br />
Architecture takes place at the juncture of design problems and their solutions. Design problems rarely arrive fully formulated or “hatched” for the architect; much of the architecture effort is to analyze or formulate the problems to be solved. Often this involves negotiation both within the enterprise and with outside stakeholders. Possible solutions are limited by resources and schedule and therefore often must also be negotiated.<br />
A dominant principle of Enterprise Architecture is '''''separation of concerns''''' (SoC). This is due to the complexity of enterprises, with many forces acting upon them; the many technologies and disciplines involved in their creation and day-to-day operations; and due to the diversity of stakeholders involved in the enterprise (see [[EIT Roles]]). <br />
An application of SoC is the '''''boundary''''' principle which is crucial to separate what is “inside” the enterprise from what is “outside”. While the former is often under the enterprise’s control, the latter is often beyond its control. <br />
For some systems, determining the boundary is a key decision, subject to many possibilities and consequences. This is perhaps less the case for enterprises whose bounds are determined by the extent of organizations, regulations, supply chains or other criteria. Within an established boundary, the '''''holism''''' principle applies: to treat the enterprise as a unified whole, and, in particular, with respect to the '''''interaction''''' of the enterprise with its ''environment''—including stakeholders, other enterprises and systems. From an enterprise IT perspective, an enterprise is a ''system of systems. '' SoC offers a way to focus on the constituent systems in terms of their interconnections to one another to form the enterprise.<br />
Another useful application of SoC is to apply the principle of '''''multiple views''''' to depict the architecture of the enterprise in different ways to address the diverse interests (i.e., ''concerns'') of an enterprise’s various stakeholders. Each ''architecture view'' presents a specific perspective on the enterprise. To be understandable to its audiences (those various stakeholders), each view should follow the conventions of its ''architecture viewpoint'' (ISO/IEC/IEEE 42010 2011). Just as a map should have a legend, each view should have a documented viewpoint providing a prescribed set of conventions for looking at the enterprise through the resulting view. A viewpoint definition serves as a contract between the architect and stakeholders on ''how'' a selected set of concerns are to be addressed. Each viewpoint allows the architect to consider the enterprise in terms of various kinds of elements and relations among them and to present that view to those “concerned” stakeholders. Dominating concerns in enterprise architecture include interoperability, quality of systems and services, operations, managing change, and alignment with the enterprise’s mission, market, and technology. Via the principle of '''''dualism''''', we recognize that some viewpoints are paired, such as with process/data duality. Another pervasive duality in the enterprise is of people/technology in terms of what capabilities are automated and which are performed by people.<br />
In support of enterprise architecture, there are numerous ''enterprise architecture frameworks'' each providing a pre-defined, integrated set of viewpoints to frame typical, recurring concerns (ISO/IEC/IEEE 42010 Users Group 2022). The earliest recorded framework was (Hammer et al. 1986), developed in the mid-1980s in response to growing availability of distributed computing to the enterprise (Rivera 2013). In the late 1980s, US NIST created its Enterprise Architecture Model as a guide for US federal departments to organize their IT offerings (Fong and Goldfine 1989). NIST’s 5-layer model remains influential today. Despite never using the term “enterprise,” Zachman’s information systems architecture has had a major influence on how subsequent frameworks have been organized and depicted using grids or cubes. Later frameworks have evolved in response to emerging concepts, such as the move from client-server to service-oriented applications, as in the OASIS SOA Reference Model and its associated framework. The 1990s saw a proliferation of frameworks for defense enterprises including US DODAF, UK MODAF, NATO’s NAF and led to successors such as OMG’s UAF.<br />
Yet another application of '''''separation of concerns''''' is distinguishing today’s needs versus facilitating future needs; balancing '''''stability/change''''' and highlighting the temporal planning aspect of architecture of the enterprise. In concert with applying SOC, the architect uses the principle of '''''abstraction''''' to “forget” some details of the subject and thus focus on essentials. Just as SoC is a way of taking things apart, '''''abstraction''''' is a way of unifying or putting like things together through generalization. These two principles are perhaps the most central to architecture. SoC and abstraction work together: SoC picks out subjects and abstraction helps architects to focus upon the essentials of each subject. <br />
Returning to the '''''boundary''''' and '''''holism''''' principles, the enterprise architect applies these recursively. As architecting proceeds, the internal details of the enterprise become known in terms of '''''interaction''''' among its parts and other '''''relations'''''. Again, '''''multiple views''''' are used to factor specific '''''relations'''''into distinct views. Typical relations include Causality, Dependency, Client-Server, and Input-Output. <br />
There are a variety of ways to structure the enterprise based upon stakeholder needs, mission or charter, technologies or capabilities already in place. Among these are structuring principles including: <br />
* '''''Modularity''''' (separate and group capabilities into modules by commonalities); <br />
* '''''Network''''' (modules are linked together); <br />
* '''''Encapsulation''''' (separating architecture modules use from how they are implemented); <br />
* '''''Layer Hierarchy''''' (separation through gradual refinement); <br />
* ''''' Regularity''''' (uniformity of interactions, of structure within layer, within network). <br />
* ''''' Similarity/Difference''''' (recognizing the limits of Regularity)<br />
A simple pattern for architecture has been defined (Hofmeister ''et al. '' 2007). Its elements are Analysis, Synthesis and Evaluation. See Figure 1 below. <br />
''Architecture Analysis'' formulates architecturally-significant requirements (ASRs)—those requirements which influence an enterprise’s architecture. Architecture analysis is based on identified concerns and other information based on understanding the enterprise’s environment, known requirements, stakeholder needs and any constraints. ASRs reflect the “design problems” that the architecture must solve. In many cases, negotiations take place to modify incoming needs, requirements and expectations to make solutions possible. The result of this activity takes the form of ASRs, including architecture principles and initial enterprise-wide decisions.<br />
''Architecture Synthesis'' develops candidate solutions in response to the concerns and ASRs. During Synthesis the architect works out the details of solutions to the identified design problems, tradeoff and interactions between them which are likely to generate further design problems. Synthesis elaborates the ASRs, principles and initial decisions into more detailed solution elements. The principle of ''''' EQUIFINALITY''''' reminds us that for many stable situations (i.e., states of the enterprise), there are many ways to reach those states.<br />
''Architecture Evaluation'' validates whether chosen solutions satisfy ASRs or whether rework is needed (ISO/IEC/IEEE 42030 2019).<br />
Applying the principles discussed above is pervasive in enacting the Analysis–Synthesis–Evaluation pattern iteratively. <br />
<br />
[[File:SEBoK EIT Figure 1.png|thumb|Figure 1. A pattern for Architecture.]] <br />
<br />
While there are many commonalities among EIT, systems and software architectures, Figure 2 addresses the relationships ''between'' them. Viewing an enterprise as a system, the EIT architecture governs the fundamental IT decisions of the enterprise. That enterprise might be extended to “outsiders” such as vendors, suppliers and perhaps customers. Depending upon the enterprise, the ''governs'' relationship may entail very strict rules or loose guidance. <br />
Within the enterprise, the ecosystem of systems, applications and data may be viewed as a system of systems. The EIT Architecture constrains the architectures governing individual systems, applications and data stores within the enterprise, so that these are able to interoperate and otherwise “play nicely” together.<br />
<br />
[[File:EIT Figure 2.png|thumb|Figure 2. Relating Enterprise IT, Systems and Software Architecture.]] <br />
<br />
===Strategy and Governance===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance] for additional information. ''<br />
<blockquote><br />
[http://eitbokwiki.org/Glossary#eit Enterprise information technology] (EIT) governance is the established process of defining the strategy for the EIT organization and overseeing its execution to achieve enterprise goals. Strategic planning translates the larger enterprise’s goals into EIT goals and defines what EIT must do to achieve those goals. This effort then communicates this hierarchy of goals: EIT goals as well as how they support the enterprise’s goals. EIT governance drives needed changes to achieve those goals, while maintaining agreed levels of operation. Taking into account various perspectives (such as financial, historical, environmental, and future projections), a strategic plan is a roadmap for action and change, both vertically and horizontally, across the EIT organization. The EIT organization’s strategic plans are based on the enterprise’s strategic plans, focusing on EIT’s role in them; EIT governance provides a monitoring and control framework to achieve strategic goals and objectives. Thus, EIT governance is essential for achieving the EIT strategy and goals..<br />
-[http://eitbokwiki.org/Strategy_and_Governance EITBOK wiki]<br />
</blockquote><br />
<br />
The principle of ''''' PARSIMONY''''' applies here, too (see [[Principles of Systems Thinking]]). These principles will be designated in this article with '''''bold italics'''''. For example, the simplest possible measurement and reporting systems are most likely to be used and not corrupted. Similarly, the EIT organizational structure should be straightforward and easy to traverse so that staff can communicate and problem-solve in teams.<br />
In governing the EIT organization to meet its dual goals of satisfying its customers and meeting its budget and schedule commitments, EIT management encounters the difficulty of managing in the face of '''''dualism''''', “ensuring a constant dynamic balance often through a cyclic dominance of one element and then the other”. The most obvious instance of handling ''''' dualism''''' in EIT is the trade-off between budget, project prioritization and features within projects.<br />
===Change===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Change_Initiatives Change Initiatives] for more information. ''<br />
There are two levels of change management discussed in the EITBOK: organizational change management and changes to the IT organization’s assets, whether they be software, hardware, or telecommunications systems.<br />
In the larger sense, the introduction of new systems and services often also requires changes in people’s jobs and in the processes used to accomplish those jobs. Such efforts are intended to increase business value. Such changes require change initiatives because they involve guiding a mixture of stakeholders through the change process. This is one aspect of [http://eitbokwiki.org/Change_Initiatives change management].<br />
Change also occurs when existing systems or services must be updated to meet new needs. Depending on the scope of the proposed changes, a change initiative may be required in this situation, too. At any rate, a change request process must be initiated and tracked to disposition (deferral, rejection, or implementation). Changes also come about as a result of defect reports. In such cases, the defect report must be tracked throughout the report’s life cycle, to disposition (deferral, rejection, or implementation).<br />
These latter types of change management are discussed in detail in the EITBOK’s section on [http://eitbokwiki.org/Operations_and_Support Operations and Support].<br />
===Interoperability of Component Systems===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Interoperability interoperability] for more information. ''<br />
As explained in the [http://eitbokwiki.org/Interoperability#One EITBOK], ''interoperability'' means “the ability of systems (including organizations) to exchange and use exchanged information without knowledge of the characteristics or inner workings of the collaborating systems (or organizations).” This definition is based on an ISO definition: “degree to which two or more systems, products, or components can exchange information and use the information that has been exchanged.” (ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models, 4.2.3.2. ) Note that this definition includes hardware components as well as software systems and the organizations in which they are used.<br />
Because technology changes so rapidly, and organizations themselves are frequently changing, achieving and maintaining interoperability is crucial. It is one of the main reasons that providing IT services is difficult and how it differs from engineering and delivering finished products, whether off-the-shelf products or bespoke systems.<br />
===Security of Systems and Data===<br />
<blockquote><br />
There are only two types of companies: those that have been hacked, and those that will be.<br />
-FBI Director Robert Mueller, October 2012<br />
</blockquote><br />
<br />
<blockquote><br />
There are two kinds of big companies in the United States. There are those who've been hacked by the Chinese and those who don't know that they've been hacked by the Chinese<br />
-FBI Director James Comey, October 2014<br />
</blockquote><br />
''See the EITBOK’s section on [http://eitbokwiki.org/Security security] for additional information. ''<br />
While there are many definitions for security, most include the three dimensions of confidentiality, integrity, and availability (sometimes referred to as the [http://eitbokwiki.org/Glossary#ciatriad CIA triad]). As such, the primary goal of EIT security is to preserve the confidentiality, integrity, and availability of information and information systems. <br />
The principles behind an organization’s [http://eitbokwiki.org/Glossary#isms information security management system] (ISMS) should be to design, implement, and maintain a coherent set of policies, processes, and systems that keep the risks associated with its information assets at a tolerable level, and yet, manage the cost and inconvenience of said risk management. As such, the goals of EIT security are to:<br />
* Always understand the current risk tolerance of the enterprise with respect to information and device security.<br />
* Understand the security threats and potential damages to information, devices, and individuals.<br />
* Create and follow policies and procedures that keep cyberattack risk and damages at or below a tolerable level.<br />
* Effectively and efficiently detect and deal with<br />
[http://eitbokwiki.org/Security#One cyberattack incidents].<br />
Ensuring security in EIT has been made even more pressing and more difficult by the proliferation of mobile devices in enterprises and their ever-increasing use to conduct business. Increasingly, personal devices (Bring Your Own Device – BYOD) are used, accessing both corporate networks and public networks. The cost of [https://www.checkpoint.com/downloads/products/check-point-mobile-security-survey-report2013.pdf mobile security incidents] very easily can outweigh the cost of the mobile device itself. <br />
==Quality of Systems and Services==<br />
The Enterprise ''Information'' Technology organization has, since its origins, had as its primary responsibility the timely provision of information to the larger organization. The information is expected to be not only timely, but also accurate and relevant. While the EIT organization itself may not be responsible for creating the data, it is responsible for the physical and logical validity and [https://simplicable.com/new/data-integrity-vs-data-quality integrity of the data] that is used to construct information. It is for this reason that defining and using appropriate processes is essential to ensure high-quality operation, including the development or acquisition, implementation and integration of new or changed capabilities.<br />
The EITBoK details the quality concepts of<br />
* How to approach measuring [http://eitbokwiki.org/Quality#Measuring_Quality Quality]<br />
* The importance of Quality in [http://eitbokwiki.org/Quality#Requirements_Management Requirements Management]<br />
* Understanding an organization’s [http://eitbokwiki.org/Quality#Quality_Capability Quality Capability]<br />
* The differences between [http://eitbokwiki.org/Quality#QMS_and_QC_vs._QA QMS, QC and QA]<br />
* Cost of Quality in [http://eitbokwiki.org/Quality#Technical_Debt_and_the_Cost_of_Rework Technical Debt and the Cost of Rework]<br />
==Disaster Preparedness==<br />
<br />
As explained in the [http://eitbokwiki.org/Disaster_Preparedness EITBOK], disaster preparedness and [http://eitbokwiki.org/Glossary#dr disaster recovery] (DR) support business-continuity planning and include planning for EIT resiliency, as well as recovery from adversity, so that critical business services affected are restored to a satisfactory working state within an [http://eitbokwiki.org/Glossary#acceptable acceptable] timeframe after an event.<br />
The EITBoK devotes a chapter to how the EIT organization and its parent must plan in advance for how it will provide sufficient organizational resilience to recover from disasters and return to normal operation as rapidly as possible.<br />
It provides the following examples of disasters and service interruptions that could occur and should be considered in prevention and recovery planning:<br />
These are examples of disasters:<br />
* Natural disaster affecting datacenters or EIT service operations (flood, fire, earthquake, wind)<br />
* Security breach resulting in a disaster (destruction of data, admin password changes, virus/malware installation, sabotage)<br />
* Usage error (accidental deletion, unplug/turn off system resulting in corruption)<br />
* Utility failure affecting datacenters (loss of power even after UPS)<br />
* Vendor failure (cloud provider security failure, oil spill)<br />
* Staffing issue (employment dispute/walkout, epidemic)<br />
These are examples of unpreparedness:<br />
* Requiring use of computers or printers when power is out<br />
* Requiring use of Internet when power or connectivity is out<br />
* Single point of knowledge/control for administration access<br />
* Lack of offsite backup storage<br />
* Lack of working restoration from backups<br />
* Lack of failover datacenters in separate locations<br />
* Undocumented or out-of-date documentation for system interfaces<br />
*Requiring use of phones that are out of power<br />
* Lack of designation of leaders in restoration efforts (who is in charge of restoring service and they know they are in charge)<br />
* In general, no cohesive, comprehensive EIT service restoration plan<br />
==Operations and Support of Delivered Systems and Services==<br />
[http://eitbokwiki.org/Operations_and_Support Operations and support activities] focus on maintaining an operation normal state in EIT environments, meaning that systems and processes execute according to expectations, with no surprises to users. This desired normal state requires the careful management of EIT assets and services via Operations, as well as of users via Support.<br />
Normal states can be disrupted either by the expected and planned transition of an asset, or by an unexpected event, be it as large as a disaster or by the discovery of a system defect. In the former case, the Disaster Recovery Plan is executed; in the latter, incident management kicks in when a system halts, or problem management is exercised when an operational system is not functioning as expected. The processes needed to ensure effective application of these complex functions is detailed in the [http://eitbokwiki.org/Operations_and_Support#Guiding_Principles Operations and Support Knowledge Area] within the EITBOK. <br />
ISO/IEC/IEEE 20000 may be used by any organization to develop and manage EIT operations, along with the current version of [https://www.servicenow.com ITIL].<br />
ITIL for many is the tool of choice for the operations and infrastructure side of IT, particularly for IT services. <br />
==Ethics==<br />
See the EITBOK’s section on [http://eitbokwiki.org/Ethics ethics] for additional information.<br />
Both the IEEE and ACM require their members to adhere to Codes of Ethics. See the [https://www.ieee.org/about/corporate/governance/p7-8.html IEEE Code of Ethics] and [https://www.acm.org/code-of-ethics ACM Code of Ethics and Professional Conduct]. Both of these can be downloaded freely. In addition, the IEEE Computer Society and the ACM worked together on the [https://dl.acm.org/action/downloadSupplement?doi=10.1145%2F265684.265699&file=acm-se-code-of-ethics.html Software Engineering Code of Ethics] (also available [https://dl.acm.org/doi/10.1145/265684.265699 here]).<br />
The organization should create an easily accessible Code of Ethics:<br />
* Ethical assertions should be documented and socialized in EIT in the form of a Code of Ethics, tied to the overall business code of ethics, and signed off by all staff so that violations can be cause for reprimand or dismissal.<br />
* Vendors should be held to similar ethical standards.<br />
* Lists of employees who have signed off on the Code of Ethics are maintained by EIT governance.<br />
The EITBOK has identified EIT ethical topics that include:<br />
* Those actions and decisions that may be illegal<br />
* Consideration of the social impact of the work at hand—if it will cause harm<br />
* Alignment of business and EIT strategies and policies to an ethical standard<br />
* Incorporation of the ideals of professionalism<br />
* Adherence to applicable regulatory intent<br />
* Protection for whistle blowers<br />
Areas to specifically highlight:<br />
* Activities that interfere with or corrupt the proper function of computers, applications and systems<br />
* Activities that interfere with digital privacy or intellectual rights of others<br />
* Respect for confidentiality, privacy, permissions, and access rights<br />
* Inappropriate bias (skewing) of analysis and reporting<br />
* Inaction in the face of likely ethics violations<br />
==EIT Roles==<br />
Several roles play a part in accomplishing the EIT organization’s mission. Just as a systems engineer can play several roles in a given project, so might several people in an EIT project combine to fulfill the systems engineering function. <br />
The function of EIT systems engineering is to orchestrate systems development, delivery and operation such that the larger organization achieves favorable outcomes in complex environments. Unlike systems projects that are built for known problems, EIT systems may change in unpredictable ways. A primary concern focuses on how quickly systems adapt to change. This entails a type of resiliency based on skills in establishing options and alternative solutions as well as strategies tailored to the volatility of changing needs and available technologies. It also requires expertise in assuring that systems quality is assured from the start.<br />
Different countries, geographic areas and organizations do not always use the same terminology to reference the functions that the roles contributing to systems engineering perform. The following section will provide information about some major international models for defining EIT skills and capabilities. Generally, though, the necessary roles across the product life cycle include these:<br />
* Business Sponsor/Champion<br />
* Enterprise Architect<br />
* Systems Engineer<br />
* Financial Manager<br />
* Application Architect<br />
* Business Analyst and/or Process Analyst<br />
* Data Analyst and/or Data Architect<br />
* Software Engineer and/or Programmer<br />
* Quality Assurance & Testing<br />
* Network Engineer<br />
* Telecoms Engineer<br />
* Integration Expert <br />
* Transition to Operations Manager<br />
* Release Manager<br />
* Availability Manager<br />
* Capacity Manager<br />
* Change Manager<br />
* Configuration Manager<br />
* EIT Operations Manager<br />
* Incident Management<br />
* Problem Manager<br />
* Service Level Manager<br />
* Database Administrator<br />
* Network Manager<br />
* Product Manager<br />
System engineering activities orchestrate the work of these roles so that they function together, rather than in silos or at cross purposes.<br />
==Examples of Systems Engineering in EIT==<br />
Systems Engineering provides a holistic discipline for integrating and managing the contributions of all roles needed to establish and provide EIT products and services. It ensures that a single perspective does not dominate outcomes; instead, it seeks balance among the many disciplines represented above in creating a consistent product or service that meets the interests and needs of enterprise users (and, perhaps, partners). It boils down to common sense, technical sense, knowing when to ask the right questions, and getting the data to support the answers to those questions. System Engineering achieves this via Systems Engineers. In many instances, though, the SE function is accomplished through Project Management approaches using Integrated Product Teams that include technical experts. Thus, although not specifically calling out a Systems Engineering function, the use of IPTs involved the use of SE practices.<br />
A doctoral dissertation from Purdue University performed a survey and causal analysis of project failures and of accidents(Aloisio, 2018). The results were similar to those found in reviews of IBM consulting projects in the 1990s . The following are examples of Systems Engineering interventions that prevented project failures. Almost all point to the lack of the System Engineering balancing act needed for product delivery.<br />
* A widely used document processing product was undergoing a major upgrade. The new VP of Engineering wanted a project review before committing to a schedule. The review showed that the proposed schedule only considered the development effort and did not give sufficient weight to the voices of the testing and documentation organizations, while the needs of the tech support group had been completely overlooked. By establishing an integrated product management team that included technical expertise, as well as expertise in work breakdown and estimating, a realistic effort was defined and the resulting 9-month schedule was met within 3 weeks.<br />
* A Silicon Valley start-up was depending entirely on an offshore development effort to produce its first product. All senior management was in the U.S. The VP of engineering made monthly visits to the development team. The CEO began to feel uneasy about the team’s ability to deliver on schedule sensing that a lot of finger pointing within the development team itself signaled problems. There was no SE or IPT guiding the project. The VP of Engineering seemed unable to sort things out. A project review showed that the probable delivery date was at least 6 months beyond what the CEO was being told. The project was shut down.<br />
* A major player in Human Resource Management had made commitments to deliver a new product. The project involved more than 100 people across the U.S. The delivery date kept slipping. Project roll-out would involve both installation of software and hardware at client sites, as well as installation and staff training at the large, centrally located Client Services organization. Executive Management needed to decide whether to reorganize this very expensive effort or cancel it. Again, the successful solution depended on establishing an effective cross-functional team (IPT) that necessarily included representatives from the technical teams. The IPT was supported by a newly established Project Management Office (PMO). The PMO integrated the geographically disparate efforts by establishing communication channels, as well as common estimating and scheduling practices. The PMO also instituted monthly critical metrics reports to show the IPT bottlenecks and inefficiencies across the project, from development efforts to Client Services set-up to Payroll technical support.<br />
There are far more examples of the lack of systems engineering practices in EIT projects than in their successful use (unfortunately, this seems also to be true in lots of software projects outside of EIT). Systems Engineering provides a holistic discipline for integrating and managing the contributions of all of the roles needed to provide EIT products and services. It ensures that a single perspective does not dominate outcomes.<br />
==Key External Models of EIT Organizational Capability and Maturity==<br />
Because EIT is critical to businesses globally, considerable effort has gone into establishing universal frameworks for EIT skills, along with definitions of levels of capability of each skill. In addition, at least 2 models have been developed for evaluating the organizational performance of EIT. The effectiveness of systems engineering is key to the effectiveness of the EIT organization.<br />
===IT-CMF: IT-Capability Maturity Framework=== <br />
The IT-CMF had its origin in a quality improvement effort at Intel Labs Europe in Ireland. Its intent, as described at the <br />
[https://cio-wiki.org/wiki/IT_Capability_Maturity_Framework_(IT-CMF) CIO Index website] was to quantify and demonstrate the true value impact of IT. IT-CMF is used to measure, develop, and monitor an organization’s EIT capability maturity. It consists of 35 EIT management capabilities organized into four macro capabilities: managing EIT like a business; managing the EIT budget; managing the EIT capability; and managing EIT for business value. Its 35 critical capabilities (CCs) are [http://eitbokwiki.org/Enterprise_IT_Maturity_Assessment described] as “A defined EIT management domain that helps mobilize and deploy EIT-based resources to effect a desired end, often in combination with other resources and capabilities”. <br />
===CMMI: Capability Maturity Model Integration (US)===<br />
The CMMI had its origin in 1987 in a model requested by the U.S. Department of Defense for determining the capability maturity of contractor software development organizations. This became the Capability Maturity Model (CMM). Since then, it has been expanded into a set of Capability Maturity Models, all based on five levels of demonstrably increasing maturity as measured by organization performance. That set was then integrated and became the CMMI. The CMMI set addresses [https://cmmiinstitute.com/dev Development], [https://cmmiinstitute.com/svc Services], [https://cmmiinstitute.com/sm Supplier Management], [https://cmmiinstitute.com/pm People Management], and [https://cmmiinstitute.com/dm Data Management].<br />
===SFIA: Skills Framework for the information Age (Europe, Canada and US)===<br />
The SFIA Framework has been downloaded and used by organizations and individuals in nearly 180 countries. It can be downloaded for free at [https://www.sfia-online.org]. It identifies 97 professional skills across EIT and supporting areas with seven levels of responsibility, which provide generic levels of responsibility, taking into account reflect experience and competency. These describe the behaviors, values, knowledge, and characteristics that an individual should have in order to be considered competent at a particular level.<br />
===E-CF: European Competency Framework (EU)===<br />
The ECF was the first sector-specific implementation of the European Qualifications Framework (EQF). The European Norm (EN) 16234-1 European e-Competence Framework (e-CF) provides a reference of 41 competences as applied at the Information and Communication Technology (ICT) workplace, using a common European reference for competences, skills, knowledge and proficiency levels. The E-CF Explorer web tool is available [https://ecfexplorer.itprofessionalism.org/ online].<br />
===I Competency Dictionary: EIT skills as Defined by METI/ IPA (Japan)===<br />
The Japanese government’s Information-Technology Promotion Agency (IPA), established by the Ministry of Economy, Trade and Industry (METI) developed the ”I Competency Dictionary” (iCD) to support the IT Engineers Examination. It underlies the METI/IPA Skills Standards for IT Professionals, abbreviated as ITSS, established in 2002. ITSS organizes skills within the information services industry into 11 job categories and 35 specialty fields. In each field, there are seven levels of competence based on individual experience and ability to perform. One appealing feature of ITSS is that this standard allows engineers to draw roadmaps for their own futures and career advancement (Career Path). Approximately 90% of large enterprises and over 60% of SMEs in Japan have introduced or are considering using ITSS. Information in English is available at https://www.ipa.go.jp/english/humandev/forth.html.<br />
===ITIL: Information Technology Infrastructure Library===<br />
According to ITLIlibrary.org, the ITIL Open Guide website, “The Information Technology Infrastructure Library (ITIL) defines the organisational structure and skill requirements of an information technology organisation and a set of standard operational management procedures and practices to allow the organisation to manage an IT operation and associated infrastructure. … The [https://www.itlibrary.org/ “library”] itself continues to evolve. This comprises five distinct areas: <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Strategy ITIL Service Strategy]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Design ITIL Service Design]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Transition ITIL Service Transition]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Operation ITIL Service Operation]; and <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Continual_Service_Improvement ITIL Continual Service Improvement].”<br />
It originally grew out of a British government sponsored effort to regularize IT Service Management (ITSM). <br />
==References==<br />
===Works Cited===<br />
Fong, E.N. and A.H. Goldfine. 1989. ''Information Management Directions: The Integration Challenge. '' National Institute of Standards and Technology (NIST) Special Publication 500-167, September 1989. https://csrc.nist.rip/library/NIST%20SP%20500-167.pdf <br />
<br />
Hammer, M., T.H. Davenport and J. Champy. 1986. ''Dispersion and Interconnection: Approaches to Distributed Systems Architecture'', Cambridge, MA: CSC Index Inc. and Hammer and Company, Inc. (June 1986). Available as: https://www.globalaea.org/general/custom.asp?page=Resources <br />
<br />
Hilliard, R. 2015. “Lessons from the fundamental unity of architecting”. ''Software Engineering in the Systems Context'', editors: Ivar Jacobson and Harold 'Bud' Lawson.<br />
<br />
Hofmeister, C. et al. 2007. “A general model of software architecture design derived from five industrial approaches”. ''The Journal of Systems and Software'' 80(1). <br />
<br />
ISO/IEC 25010:2011 ''Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models'', 4.2.3.2.<br />
<br />
ISO/IEC/IEEE 42010 Users Group. ''Survey of Architecture Frameworks'' Available as: http://www.iso-architecture.org/42010/afs/<br />
<br />
ISO/IEC/IEEE. 2011. ISO/IEC/IEEE 42010:2011, ''Systems and software engineering — Architecture description. ''<br />
<br />
PMI. 2013. ''Software Extension to PMBOK® Guide – Fifth Edition. '' Newtown Square, PA, USA: Project Management Institute (PMI). Available as: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/software-extension-5th-edition.<br />
<br />
Rivera, R. 2013. “The PRISM Architecture Framework – Was it the Very First Enterprise Architecture Framework?” ''Journal of Enterprise Architecture'', November 2013<br />
<br />
Zachman, J. 1987. “A Framework for Information Systems Architecture”. ''IBM Systems Journal'', pp454-470, 1987 <br />
<br />
===Primary References===<br />
IEEE Computer Society. ''Enterprise IT Body of Knowledge''. Available: http://eitbokwiki.org<br />
<br />
=-=Additional References===<br />
IT Capability Maturity Framework (IT-CMF): The Body of Knowledge Guide. 2015. Editors. Martin Curley, Jim Kenneally, Marian Carcary. Van Haren Publishing.<br />
<br />
Lessons from Systems Engineering Failures: Determining Why Systems Fail, The State of Systems Engineering Education, and Building an Evidence-Based Network to Help Systems Engineers Identify and Fix Problems on Complex Projects, Diane Constance Aloisio, December 2018.<br />
<br />
===International Standards Guiding EIT===<br />
ANSI/AIAA. 2012. ''ANSI/AIAA Guide to the Preparation of Operational Concept Documents. '' ANSI/AIAA G-043A-2012e.<br />
<br />
IEEE 2012 Std 828™-2012, ''IEEE Standard for Configuration Management in Systems and Software Engineering. ''<br />
<br />
ISO 10004:2012, Quality management—Customer satisfaction—Guidelines for monitoring and measuring<br />
<br />
ISO 10007:2003, Quality management systems—Guidelines for configuration management<br />
<br />
ISO 18238:2015, Space systems—Closed loop problem solving management<br />
<br />
ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models<br />
<br />
ISO/IEC 16350:2015, Information technology—Systems and software engineering—Application management<br />
<br />
ISO/IEC 19770-1:2012, Information technology—Software asset management—Part 1: Processes and tiered assessment of conformance<br />
<br />
ISO/IEC 20000-1:2011, (IEEE Std 20000-1:2013) Information technology—Service management—Part 1: Service management system requirements<br />
<br />
ISO/IEC 20000–2:2012, Information technology—Service management—Part 2: Guidance on the application of service management systems<br />
<br />
ISO/IEC TR 20000–10:2015, Information technology—Service management—Part 10: Concepts and terminology<br />
<br />
ISO/IEC TR 20000–11:2015, Information technology—Service management—Part 11: Guidance on the relationship between ISO/IEC 20000-1:2011 and related frameworks: ITIL®<br />
<br />
ISO/IEC TR 20000-12—Information technology—IT Service management—Part 12: Guidance on the relationship between ISO/IEC 20000-1:2011 and service management frameworks: CMMI-SVC®<br />
<br />
ISO/IEC/IEEE 14764-2006, Software Engineering—Software Lifecycle Processes—Maintenance<br />
<br />
ISO/IEC 15939:2007, Systems and software engineering—Measurement process<br />
<br />
ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description <br />
<br />
<br />
----<br />
<center>[[ Systems Engineering and Economics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Quality Attributes|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=File:EIT_Figure_2.png&diff=66934
File:EIT Figure 2.png
2023-05-07T03:45:50Z
<p>Mhaas: Uploaded own work with UploadWizard</p>
<hr />
<div>=={{int:filedesc}}==<br />
{{Information<br />
|description={{en|1=EIT article figure showing relationships between enterprise IT, systems, and software architecture.}}<br />
|date=2023-05-06<br />
|source={{own}}<br />
|author=[[User:Mhaas|Mhaas]]<br />
|permission=<br />
|other versions=<br />
}}<br />
<br />
=={{int:license-header}}==<br />
{{licensing|generic}}<br />
<br />
[[Category:Enterprise Systems Engineering]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=File:SEBoK_EIT_Figure_1.png&diff=66933
File:SEBoK EIT Figure 1.png
2023-05-07T03:45:49Z
<p>Mhaas: Uploaded own work with UploadWizard</p>
<hr />
<div>=={{int:filedesc}}==<br />
{{Information<br />
|description={{en|1=EIT article figure showing architecture pattern}}<br />
|date=2023-05-06<br />
|source={{own}}<br />
|author=[[User:Mhaas|Mhaas]]<br />
|permission=<br />
|other versions=<br />
}}<br />
<br />
=={{int:license-header}}==<br />
{{licensing|generic}}<br />
<br />
[[Category:Enterprise Systems Engineering]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Enterprise_IT&diff=66928
Systems Engineering and Enterprise IT
2023-04-24T06:01:33Z
<p>Mhaas: </p>
<hr />
<div>----<br />
'''''Lead Authors:''''' Chuck Walrad and Richard Hilliard<br />
----<br />
This article forms part of the [[Related Disciplines]] knowledge area (KA). It discusses enterprise IT, building upon the concepts and practices of Systems Engineering presented elsewhere in the SEBOK. Systems Engineering is integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of ''engineered technical systems''. <br />
<br />
== Enterprise IT Introduction==<br />
Although it had its origin in the need to improve success rates in U.S. Government outsourcing of technical systems, Systems Engineering is also integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of [https://www.incose.org/about-systems-engineering/system-and-se-definition/systems-engineering-definition#ENGINEERED_SYSTEM engineered technical systems].<br />
Examples of EIT systems include enterprise resource planning, supply chain management and customer relationship management systems, accounting, finance, inventory and order management, marketing, planning, purchasing, and sales.<br />
In the late 1980s and throughout the 1990s, EIT organizations became increasingly aware that the success rates of IT projects were very low, and that their enterprise customers were increasingly unhappy with their EIT investments. The Standish Group sought to understand what was going on. Their findings were presented in the [https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf Chaos Report] (1994):<br />
The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable but could easily be in the trillions of dollars.<br />
As a result, commercial IT organizations, through the auspicious parallel emergence of the Total Quality Management movement and the increasingly widespread development of application development methodologies (ADM) by IT management consulting firms, recognized the need for the principles of Systems Engineering and cross-functional teams (Integrated Product Teams [https://www.sebokwiki.org/wiki/Integrated_Product_Team_(IPT)_(glossary)]. It should be noted that there is considerable overlap today between what constitutes Systems Engineering and what constitutes [[Project and Portfolio Management|Relationships between Systems Engineering and Project Management]] (see [https://www.pmi.org/learning/library/bridging-gap-program-management-systems-engineering-6213 PMI]). This article does not attempt to resolve this issue. Note that the “[[Related Business Activities|following business management activities]] can be ''supported'' by enterprise systems engineering (ESE) activities” [emphasis added]: <br />
* mission and strategic planning,<br />
* business processes and information Management,<br />
* performance management,<br />
* portfolio management,<br />
* resource allocation and budgeting, and<br />
* program and project management.<br />
Note that these same areas have been designated as being supported by Project Management Offices. However, since a key difference between project management and systems engineering has been identified as the requirement that the latter includes technical expertise in the product/system of concern, focus should be on systems engineering and integrated product teams (IPTs). <br />
With IPTs, each product is shepherded from concept through delivery and support to retirement by a cross-functional team that includes representatives from each area of responsibility, such as customer requirements development, design and development, test, configuration management, release engineering, delivery, and support.<br />
As enterprises have come to depend more and more on technology to perform effectively, Enterprise IT organizations have matured, often due to the influence of IT consulting firms that make it their business to keep abreast of best practices.<br />
<br />
== EIT Concepts ==<br />
This knowledge area (KA) discusses enterprise IT, building upon the concepts elucidated in the IEEE/ACM ''[http://eitbokwiki.org EITBOK Guide to the Enterprise Information Technology Body of Knowledge]'' and general concepts of Systems Engineering elsewhere in SEBOK. <br />
An enterprise may be viewed from various perspectives: such as a system or a [[system of systems (SoS)|Enterprise Systems Engineering]]:<br />
* system-like enterprise: enterprises, like other systems, may have a tight coupling, single-executive function; <br />
* system of systems-like enterprise: may be a loosely coupled group of organizations with blurred boundaries and (yet) with (some) shared outcomes.<br />
The choice of perspective may vary with many factors: the enterprise itself, the mission or purpose, or the particular engineering task at hand. We can view an enterprise as a system with inputs and outputs in relation to the outside world, or a system of systems interacting through their individual inputs and outputs. <br />
An enterprise usually involves one (or more) organization(s) but need not be identified with the organization. As the scope of human and organizational participants of the enterprise widen, there may be no single point of control. For example, an ''extended enterprise'' could include a company, its suppliers and customers.<br />
Whatever perspective (system-like, SoS-like, other) is taken there are [[key ingredients|Enterprise Systems Engineering Background]] of any enterprise: capabilities, individual (competencies) and the organizational design. [[Capabilities|Enterprise Capability Management]] can be further categorized: “There are three different kinds of capability: organizational capability, system capability, and operational capability.” These capabilities determine what the enterprise is able to produce which may be external offerings or internal mechanisms. Operational capabilities create services and/or products which in turn produce value as determined by stakeholders. The capabilities of an enterprise are realized through [[Enterprise Systems Engineering Background|various enterprise elements]], including: “hardware, software, personnel, facilities, data, materials, techniques, and even services”. which include “soft” items, like people, processes, principles, policies, practices, organizations, doctrine, theories, and beliefs.<br />
EIT capabilities exist through lifecycles spanning from creation through eventual replacement and disposal. ''Life cycle models'' are schemes to aid in the understanding, design, planning and management of the capability of interest. <br />
“A life cycle for a system generally consists of a series of stages regulated by a set of management decisions which confirm that the system is mature enough to leave one stage and enter another.” Basic life cycle terms and concepts are discussed in [[System Lifecycle Approaches]]. Some typical life cycles are discussed in [[System Lifecycle Models]].<br />
A life cycle-based approach can be deployed across the several levels and used to manage evolution. These levels are:<br />
* the enterprise itself,<br />
* the processes and organizations constituting the enterprise,<br />
* the systems enabling the capabilities, services or products provided. <br />
It is important to distinguish between ''product'' and ''project'' lifecycle models. A product’s life cycle extends from its initial concept approval, through development and distribution, to its retirement. This is the cycle that is managed within an Enterprise IT organization, since EIT must manage the hardware or software product from its introduction, in the case of acquired capabilities, or from its concept approval and development, in the case of capabilities it builds, through its deployment, maintenance and eventual retirement (withdrawal). Each of these stages is usually managed as a project or a series of projects.<br />
However, most discussions of life cycles within software and systems discussions focus on ''project'' life cycles. See, for example, the ''Software Extension to PMBOK Guide'' (PMI 2013).<br />
==System of Systems Context in EIT==<br />
“Enterprise IT” (EIT) is used both to refer to the technology organization/business unit within the enterprise and to the enterprise’s information technology systems. In this article, we use EIT to refer to the technology systems. When referring to the organization, we use the phrase “Enterprise IT organization” or EIT organization. <br />
Enterprise IT organizations are responsible for complex socio-technical systems. Socio-technical systems in a business context (thus, EIT) contain technical elements (software, hardware, networks, storage, databases, etc.) but they also contain essential human components and necessary business processes. As covered in [[Introduction to Systems Engineering Fundamentals]], they exist in an engineered System Context that is a set of system component interrelationships within a real-world environment:<br />
This includes where problems come from and how they are defined, how we identify and select candidate solutions, how to balance technology and human elements in the wider solution context, how to manage the complex organizational systems needed to develop new solutions, and how developed solutions are used, sustained and disposed of. … Systems Engineering should consider the full Engineered System Context so that the necessary understanding can be reached and the right systems engineering decisions can be made. <br />
Socio-technical systems also have the following key characteristics: ''Openness'' in that they strongly interact with their environments, and ''unfinished'' in that they evolve over time.<br />
A complex of EIT systems is essential to the successful functioning of the humans in the enterprise. They rely on EIT’s technology for communication, for paying employees, for people management, for business measurement, and often for managing supply chains. Thus, “EIT needs to be viewed as a strategic partner to all the other functions and business units within an enterprise. This means that the results produced by EIT along with its effectiveness and efficiency are all critically important to the success of the enterprise.” [http://eitbokwiki.org/What_is_the_Enterprise_Perspective%3F]<br />
To accomplish this mission, the EIT organization builds and acquires new systems or system components, integrates them into the mega System of Systems, and maintains the integrity and interoperability of the individual components, but also the integrity of the entire complex of systems. In addition, security and performance levels must be achieved, benchmarked and maintained or improved.<br />
==Major concerns of the EIT Organization==<br />
The [http://eitbokwiki.org ''Enterprise IT Body of Knowledge''] provides a good deal of information about these major concerns, which we will not replicate here. Rather, links to the relevant areas are provided. The EITBOK demonstrates how, in providing technology systems and services to the enterprise, the EIT organization must skillfully manage such concerns as the following.<br />
<br />
===Enterprise Architecture===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Enterprise_Architecture Enterprise Architecture] for additional information. ''<br />
[http://eitbokwiki.org/Glossary#ea ''Enterprise architecture''] (EA) is the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. EA applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their organization's strategies. Enterprise architecture builds upon many of the concepts and practices of [[System Architecture Definition|systems architecture]] and also software architecture [https://www.sebokwiki.org/wiki/System_Architecture_Definition].<br />
This section will discuss Enterprise Architecture from the perspective of key [[Principles of Systems Thinking]], designated in this article with '''''bold italics'''''. There are many commonalities in architecture whether one is architecture systems, software or the enterprise [Unity]. In this article we highlight both commonalities and differences between Enterprise Architecture and Systems Architecture. <br />
Architecture takes place at the juncture of design problems and their solutions. Design problems rarely arrive fully formulated or “hatched” for the architect; much of the architecture effort is to analyze or formulate the problems to be solved. Often this involves negotiation both within the enterprise and with outside stakeholders. Possible solutions are limited by resources and schedule and therefore often must also be negotiated.<br />
A dominant principle of Enterprise Architecture is '''''separation of concerns''''' (SoC). This is due to the complexity of enterprises, with many forces acting upon them; the many technologies and disciplines involved in their creation and day-to-day operations; and due to the diversity of stakeholders involved in the enterprise (see [[EIT Roles]]). <br />
An application of SoC is the '''''boundary''''' principle which is crucial to separate what is “inside” the enterprise from what is “outside”. While the former is often under the enterprise’s control, the latter is often beyond its control. <br />
For some systems, determining the boundary is a key decision, subject to many possibilities and consequences. This is perhaps less the case for enterprises whose bounds are determined by the extent of organizations, regulations, supply chains or other criteria. Within an established boundary, the '''''holism''''' principle applies: to treat the enterprise as a unified whole, and, in particular, with respect to the '''''interaction''''' of the enterprise with its ''environment''—including stakeholders, other enterprises and systems. From an enterprise IT perspective, an enterprise is a ''system of systems. '' SoC offers a way to focus on the constituent systems in terms of their interconnections to one another to form the enterprise.<br />
Another useful application of SoC is to apply the principle of '''''multiple views''''' to depict the architecture of the enterprise in different ways to address the diverse interests (i.e., ''concerns'') of an enterprise’s various stakeholders. Each ''architecture view'' presents a specific perspective on the enterprise. To be understandable to its audiences (those various stakeholders), each view should follow the conventions of its ''architecture viewpoint'' (ISO/IEC/IEEE 42010 2011). Just as a map should have a legend, each view should have a documented viewpoint providing a prescribed set of conventions for looking at the enterprise through the resulting view. A viewpoint definition serves as a contract between the architect and stakeholders on ''how'' a selected set of concerns are to be addressed. Each viewpoint allows the architect to consider the enterprise in terms of various kinds of elements and relations among them and to present that view to those “concerned” stakeholders. Dominating concerns in enterprise architecture include interoperability, quality of systems and services, operations, managing change, and alignment with the enterprise’s mission, market, and technology. Via the principle of '''''dualism''''', we recognize that some viewpoints are paired, such as with process/data duality. Another pervasive duality in the enterprise is of people/technology in terms of what capabilities are automated and which are performed by people.<br />
In support of enterprise architecture, there are numerous ''enterprise architecture frameworks'' each providing a pre-defined, integrated set of viewpoints to frame typical, recurring concerns (ISO/IEC/IEEE 42010 Users Group 2022). The earliest recorded framework was (Hammer et al. 1986), developed in the mid-1980s in response to growing availability of distributed computing to the enterprise (Rivera 2013). In the late 1980s, US NIST created its Enterprise Architecture Model as a guide for US federal departments to organize their IT offerings (Fong and Goldfine 1989). NIST’s 5-layer model remains influential today. Despite never using the term “enterprise,” Zachman’s information systems architecture has had a major influence on how subsequent frameworks have been organized and depicted using grids or cubes. Later frameworks have evolved in response to emerging concepts, such as the move from client-server to service-oriented applications, as in the OASIS SOA Reference Model and its associated framework. The 1990s saw a proliferation of frameworks for defense enterprises including US DODAF, UK MODAF, NATO’s NAF and led to successors such as OMG’s UAF.<br />
Yet another application of '''''separation of concerns''''' is distinguishing today’s needs versus facilitating future needs; balancing '''''stability/change''''' and highlighting the temporal planning aspect of architecture of the enterprise. In concert with applying SOC, the architect uses the principle of '''''abstraction''''' to “forget” some details of the subject and thus focus on essentials. Just as SoC is a way of taking things apart, '''''abstraction''''' is a way of unifying or putting like things together through generalization. These two principles are perhaps the most central to architecture. SoC and abstraction work together: SoC picks out subjects and abstraction helps architects to focus upon the essentials of each subject. <br />
Returning to the '''''boundary''''' and '''''holism''''' principles, the enterprise architect applies these recursively. As architecting proceeds, the internal details of the enterprise become known in terms of '''''interaction''''' among its parts and other '''''relations'''''. Again, '''''multiple views''''' are used to factor specific '''''relations'''''into distinct views. Typical relations include Causality, Dependency, Client-Server, and Input-Output. <br />
There are a variety of ways to structure the enterprise based upon stakeholder needs, mission or charter, technologies or capabilities already in place. Among these are structuring principles including: <br />
* '''''Modularity''''' (separate and group capabilities into modules by commonalities); <br />
* '''''Network''''' (modules are linked together); <br />
* '''''Encapsulation''''' (separating architecture modules use from how they are implemented); <br />
* '''''Layer Hierarchy''''' (separation through gradual refinement); <br />
* ''''' Regularity''''' (uniformity of interactions, of structure within layer, within network). <br />
* ''''' Similarity/Difference''''' (recognizing the limits of Regularity)<br />
A simple pattern for architecture has been defined (Hofmeister ''et al. '' 2007). Its elements are Analysis, Synthesis and Evaluation. See Figure 1 below. <br />
''Architecture Analysis'' formulates architecturally-significant requirements (ASRs)—those requirements which influence an enterprise’s architecture. Architecture analysis is based on identified concerns and other information based on understanding the enterprise’s environment, known requirements, stakeholder needs and any constraints. ASRs reflect the “design problems” that the architecture must solve. In many cases, negotiations take place to modify incoming needs, requirements and expectations to make solutions possible. The result of this activity takes the form of ASRs, including architecture principles and initial enterprise-wide decisions.<br />
''Architecture Synthesis'' develops candidate solutions in response to the concerns and ASRs. During Synthesis the architect works out the details of solutions to the identified design problems, tradeoff and interactions between them which are likely to generate further design problems. Synthesis elaborates the ASRs, principles and initial decisions into more detailed solution elements. The principle of ''''' EQUIFINALITY''''' reminds us that for many stable situations (i.e., states of the enterprise), there are many ways to reach those states.<br />
''Architecture Evaluation'' validates whether chosen solutions satisfy ASRs or whether rework is needed (ISO/IEC/IEEE 42030 2019).<br />
Applying the principles discussed above is pervasive in enacting the Analysis–Synthesis–Evaluation pattern iteratively. <br />
<br />
<br />
Figure 1 A pattern for Architecture<br />
While there are many commonalities among EIT, systems and software architectures, Figure 2 addresses the relationships ''between'' them. Viewing an enterprise as a system, the EIT architecture governs the fundamental IT decisions of the enterprise. That enterprise might be extended to “outsiders” such as vendors, suppliers and perhaps customers. Depending upon the enterprise, the ''governs'' relationship may entail very strict rules or loose guidance. <br />
Within the enterprise, the ecosystem of systems, applications and data may be viewed as a system of systems. The EIT Architecture constrains the architectures governing individual systems, applications and data stores within the enterprise, so that these are able to interoperate and otherwise “play nicely” together.<br />
<br />
Figure 2 Relating Enterprise IT, Systems and Software Architecture<br />
===Strategy and Governance===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance] for additional information. ''<br />
<blockquote><br />
[http://eitbokwiki.org/Glossary#eit Enterprise information technology] (EIT) governance is the established process of defining the strategy for the EIT organization and overseeing its execution to achieve enterprise goals. Strategic planning translates the larger enterprise’s goals into EIT goals and defines what EIT must do to achieve those goals. This effort then communicates this hierarchy of goals: EIT goals as well as how they support the enterprise’s goals. EIT governance drives needed changes to achieve those goals, while maintaining agreed levels of operation. Taking into account various perspectives (such as financial, historical, environmental, and future projections), a strategic plan is a roadmap for action and change, both vertically and horizontally, across the EIT organization. The EIT organization’s strategic plans are based on the enterprise’s strategic plans, focusing on EIT’s role in them; EIT governance provides a monitoring and control framework to achieve strategic goals and objectives. Thus, EIT governance is essential for achieving the EIT strategy and goals..<br />
-[http://eitbokwiki.org/Strategy_and_Governance EITBOK wiki]<br />
</blockquote><br />
<br />
The principle of ''''' PARSIMONY''''' applies here, too (see [[Principles of Systems Thinking]]). These principles will be designated in this article with '''''bold italics'''''. For example, the simplest possible measurement and reporting systems are most likely to be used and not corrupted. Similarly, the EIT organizational structure should be straightforward and easy to traverse so that staff can communicate and problem-solve in teams.<br />
In governing the EIT organization to meet its dual goals of satisfying its customers and meeting its budget and schedule commitments, EIT management encounters the difficulty of managing in the face of '''''dualism''''', “ensuring a constant dynamic balance often through a cyclic dominance of one element and then the other”. The most obvious instance of handling ''''' dualism''''' in EIT is the trade-off between budget, project prioritization and features within projects.<br />
===Change===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Change_Initiatives Change Initiatives] for more information. ''<br />
There are two levels of change management discussed in the EITBOK: organizational change management and changes to the IT organization’s assets, whether they be software, hardware, or telecommunications systems.<br />
In the larger sense, the introduction of new systems and services often also requires changes in people’s jobs and in the processes used to accomplish those jobs. Such efforts are intended to increase business value. Such changes require change initiatives because they involve guiding a mixture of stakeholders through the change process. This is one aspect of [http://eitbokwiki.org/Change_Initiatives change management].<br />
Change also occurs when existing systems or services must be updated to meet new needs. Depending on the scope of the proposed changes, a change initiative may be required in this situation, too. At any rate, a change request process must be initiated and tracked to disposition (deferral, rejection, or implementation). Changes also come about as a result of defect reports. In such cases, the defect report must be tracked throughout the report’s life cycle, to disposition (deferral, rejection, or implementation).<br />
These latter types of change management are discussed in detail in the EITBOK’s section on [http://eitbokwiki.org/Operations_and_Support Operations and Support].<br />
===Interoperability of Component Systems===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Interoperability interoperability] for more information. ''<br />
As explained in the [http://eitbokwiki.org/Interoperability#One EITBOK], ''interoperability'' means “the ability of systems (including organizations) to exchange and use exchanged information without knowledge of the characteristics or inner workings of the collaborating systems (or organizations).” This definition is based on an ISO definition: “degree to which two or more systems, products, or components can exchange information and use the information that has been exchanged.” (ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models, 4.2.3.2. ) Note that this definition includes hardware components as well as software systems and the organizations in which they are used.<br />
Because technology changes so rapidly, and organizations themselves are frequently changing, achieving and maintaining interoperability is crucial. It is one of the main reasons that providing IT services is difficult and how it differs from engineering and delivering finished products, whether off-the-shelf products or bespoke systems.<br />
===Security of Systems and Data===<br />
<blockquote><br />
There are only two types of companies: those that have been hacked, and those that will be.<br />
-FBI Director Robert Mueller, October 2012<br />
</blockquote><br />
<br />
<blockquote><br />
There are two kinds of big companies in the United States. There are those who've been hacked by the Chinese and those who don't know that they've been hacked by the Chinese<br />
-FBI Director James Comey, October 2014<br />
</blockquote><br />
''See the EITBOK’s section on [http://eitbokwiki.org/Security security] for additional information. ''<br />
While there are many definitions for security, most include the three dimensions of confidentiality, integrity, and availability (sometimes referred to as the [http://eitbokwiki.org/Glossary#ciatriad CIA triad]). As such, the primary goal of EIT security is to preserve the confidentiality, integrity, and availability of information and information systems. <br />
The principles behind an organization’s [http://eitbokwiki.org/Glossary#isms information security management system] (ISMS) should be to design, implement, and maintain a coherent set of policies, processes, and systems that keep the risks associated with its information assets at a tolerable level, and yet, manage the cost and inconvenience of said risk management. As such, the goals of EIT security are to:<br />
* Always understand the current risk tolerance of the enterprise with respect to information and device security.<br />
* Understand the security threats and potential damages to information, devices, and individuals.<br />
* Create and follow policies and procedures that keep cyberattack risk and damages at or below a tolerable level.<br />
* Effectively and efficiently detect and deal with<br />
[http://eitbokwiki.org/Security#One cyberattack incidents].<br />
Ensuring security in EIT has been made even more pressing and more difficult by the proliferation of mobile devices in enterprises and their ever-increasing use to conduct business. Increasingly, personal devices (Bring Your Own Device – BYOD) are used, accessing both corporate networks and public networks. The cost of [https://www.checkpoint.com/downloads/products/check-point-mobile-security-survey-report2013.pdf mobile security incidents] very easily can outweigh the cost of the mobile device itself. <br />
==Quality of Systems and Services==<br />
The Enterprise ''Information'' Technology organization has, since its origins, had as its primary responsibility the timely provision of information to the larger organization. The information is expected to be not only timely, but also accurate and relevant. While the EIT organization itself may not be responsible for creating the data, it is responsible for the physical and logical validity and [https://simplicable.com/new/data-integrity-vs-data-quality integrity of the data] that is used to construct information. It is for this reason that defining and using appropriate processes is essential to ensure high-quality operation, including the development or acquisition, implementation and integration of new or changed capabilities.<br />
The EITBoK details the quality concepts of<br />
* How to approach measuring [http://eitbokwiki.org/Quality#Measuring_Quality Quality]<br />
* The importance of Quality in [http://eitbokwiki.org/Quality#Requirements_Management Requirements Management]<br />
* Understanding an organization’s [http://eitbokwiki.org/Quality#Quality_Capability Quality Capability]<br />
* The differences between [http://eitbokwiki.org/Quality#QMS_and_QC_vs._QA QMS, QC and QA]<br />
* Cost of Quality in [http://eitbokwiki.org/Quality#Technical_Debt_and_the_Cost_of_Rework Technical Debt and the Cost of Rework]<br />
==Disaster Preparedness==<br />
<br />
As explained in the [http://eitbokwiki.org/Disaster_Preparedness EITBOK], disaster preparedness and [http://eitbokwiki.org/Glossary#dr disaster recovery] (DR) support business-continuity planning and include planning for EIT resiliency, as well as recovery from adversity, so that critical business services affected are restored to a satisfactory working state within an [http://eitbokwiki.org/Glossary#acceptable acceptable] timeframe after an event.<br />
The EITBoK devotes a chapter to how the EIT organization and its parent must plan in advance for how it will provide sufficient organizational resilience to recover from disasters and return to normal operation as rapidly as possible.<br />
It provides the following examples of disasters and service interruptions that could occur and should be considered in prevention and recovery planning:<br />
These are examples of disasters:<br />
* Natural disaster affecting datacenters or EIT service operations (flood, fire, earthquake, wind)<br />
* Security breach resulting in a disaster (destruction of data, admin password changes, virus/malware installation, sabotage)<br />
* Usage error (accidental deletion, unplug/turn off system resulting in corruption)<br />
* Utility failure affecting datacenters (loss of power even after UPS)<br />
* Vendor failure (cloud provider security failure, oil spill)<br />
* Staffing issue (employment dispute/walkout, epidemic)<br />
These are examples of unpreparedness:<br />
* Requiring use of computers or printers when power is out<br />
* Requiring use of Internet when power or connectivity is out<br />
* Single point of knowledge/control for administration access<br />
* Lack of offsite backup storage<br />
* Lack of working restoration from backups<br />
* Lack of failover datacenters in separate locations<br />
* Undocumented or out-of-date documentation for system interfaces<br />
*Requiring use of phones that are out of power<br />
* Lack of designation of leaders in restoration efforts (who is in charge of restoring service and they know they are in charge)<br />
* In general, no cohesive, comprehensive EIT service restoration plan<br />
==Operations and Support of Delivered Systems and Services==<br />
[http://eitbokwiki.org/Operations_and_Support Operations and support activities] focus on maintaining an operation normal state in EIT environments, meaning that systems and processes execute according to expectations, with no surprises to users. This desired normal state requires the careful management of EIT assets and services via Operations, as well as of users via Support.<br />
Normal states can be disrupted either by the expected and planned transition of an asset, or by an unexpected event, be it as large as a disaster or by the discovery of a system defect. In the former case, the Disaster Recovery Plan is executed; in the latter, incident management kicks in when a system halts, or problem management is exercised when an operational system is not functioning as expected. The processes needed to ensure effective application of these complex functions is detailed in the [http://eitbokwiki.org/Operations_and_Support#Guiding_Principles Operations and Support Knowledge Area] within the EITBOK. <br />
ISO/IEC/IEEE 20000 may be used by any organization to develop and manage EIT operations, along with the current version of [https://www.servicenow.com ITIL].<br />
ITIL for many is the tool of choice for the operations and infrastructure side of IT, particularly for IT services. <br />
==Ethics==<br />
See the EITBOK’s section on [http://eitbokwiki.org/Ethics ethics] for additional information.<br />
Both the IEEE and ACM require their members to adhere to Codes of Ethics. See the [https://www.ieee.org/about/corporate/governance/p7-8.html IEEE Code of Ethics] and [https://www.acm.org/code-of-ethics ACM Code of Ethics and Professional Conduct]. Both of these can be downloaded freely. In addition, the IEEE Computer Society and the ACM worked together on the [https://dl.acm.org/action/downloadSupplement?doi=10.1145%2F265684.265699&file=acm-se-code-of-ethics.html Software Engineering Code of Ethics] (also available [https://dl.acm.org/doi/10.1145/265684.265699 here]).<br />
The organization should create an easily accessible Code of Ethics:<br />
* Ethical assertions should be documented and socialized in EIT in the form of a Code of Ethics, tied to the overall business code of ethics, and signed off by all staff so that violations can be cause for reprimand or dismissal.<br />
* Vendors should be held to similar ethical standards.<br />
* Lists of employees who have signed off on the Code of Ethics are maintained by EIT governance.<br />
The EITBOK has identified EIT ethical topics that include:<br />
* Those actions and decisions that may be illegal<br />
* Consideration of the social impact of the work at hand—if it will cause harm<br />
* Alignment of business and EIT strategies and policies to an ethical standard<br />
* Incorporation of the ideals of professionalism<br />
* Adherence to applicable regulatory intent<br />
* Protection for whistle blowers<br />
Areas to specifically highlight:<br />
* Activities that interfere with or corrupt the proper function of computers, applications and systems<br />
* Activities that interfere with digital privacy or intellectual rights of others<br />
* Respect for confidentiality, privacy, permissions, and access rights<br />
* Inappropriate bias (skewing) of analysis and reporting<br />
* Inaction in the face of likely ethics violations<br />
==EIT Roles==<br />
Several roles play a part in accomplishing the EIT organization’s mission. Just as a systems engineer can play several roles in a given project, so might several people in an EIT project combine to fulfill the systems engineering function. <br />
The function of EIT systems engineering is to orchestrate systems development, delivery and operation such that the larger organization achieves favorable outcomes in complex environments. Unlike systems projects that are built for known problems, EIT systems may change in unpredictable ways. A primary concern focuses on how quickly systems adapt to change. This entails a type of resiliency based on skills in establishing options and alternative solutions as well as strategies tailored to the volatility of changing needs and available technologies. It also requires expertise in assuring that systems quality is assured from the start.<br />
Different countries, geographic areas and organizations do not always use the same terminology to reference the functions that the roles contributing to systems engineering perform. The following section will provide information about some major international models for defining EIT skills and capabilities. Generally, though, the necessary roles across the product life cycle include these:<br />
* Business Sponsor/Champion<br />
* Enterprise Architect<br />
* Systems Engineer<br />
* Financial Manager<br />
* Application Architect<br />
* Business Analyst and/or Process Analyst<br />
* Data Analyst and/or Data Architect<br />
* Software Engineer and/or Programmer<br />
* Quality Assurance & Testing<br />
* Network Engineer<br />
* Telecoms Engineer<br />
* Integration Expert <br />
* Transition to Operations Manager<br />
* Release Manager<br />
* Availability Manager<br />
* Capacity Manager<br />
* Change Manager<br />
* Configuration Manager<br />
* EIT Operations Manager<br />
* Incident Management<br />
* Problem Manager<br />
* Service Level Manager<br />
* Database Administrator<br />
* Network Manager<br />
* Product Manager<br />
System engineering activities orchestrate the work of these roles so that they function together, rather than in silos or at cross purposes.<br />
==Examples of Systems Engineering in EIT==<br />
Systems Engineering provides a holistic discipline for integrating and managing the contributions of all roles needed to establish and provide EIT products and services. It ensures that a single perspective does not dominate outcomes; instead, it seeks balance among the many disciplines represented above in creating a consistent product or service that meets the interests and needs of enterprise users (and, perhaps, partners). It boils down to common sense, technical sense, knowing when to ask the right questions, and getting the data to support the answers to those questions. System Engineering achieves this via Systems Engineers. In many instances, though, the SE function is accomplished through Project Management approaches using Integrated Product Teams that include technical experts. Thus, although not specifically calling out a Systems Engineering function, the use of IPTs involved the use of SE practices.<br />
A doctoral dissertation from Purdue University performed a survey and causal analysis of project failures and of accidents(Aloisio, 2018). The results were similar to those found in reviews of IBM consulting projects in the 1990s . The following are examples of Systems Engineering interventions that prevented project failures. Almost all point to the lack of the System Engineering balancing act needed for product delivery.<br />
* A widely used document processing product was undergoing a major upgrade. The new VP of Engineering wanted a project review before committing to a schedule. The review showed that the proposed schedule only considered the development effort and did not give sufficient weight to the voices of the testing and documentation organizations, while the needs of the tech support group had been completely overlooked. By establishing an integrated product management team that included technical expertise, as well as expertise in work breakdown and estimating, a realistic effort was defined and the resulting 9-month schedule was met within 3 weeks.<br />
* A Silicon Valley start-up was depending entirely on an offshore development effort to produce its first product. All senior management was in the U.S. The VP of engineering made monthly visits to the development team. The CEO began to feel uneasy about the team’s ability to deliver on schedule sensing that a lot of finger pointing within the development team itself signaled problems. There was no SE or IPT guiding the project. The VP of Engineering seemed unable to sort things out. A project review showed that the probable delivery date was at least 6 months beyond what the CEO was being told. The project was shut down.<br />
* A major player in Human Resource Management had made commitments to deliver a new product. The project involved more than 100 people across the U.S. The delivery date kept slipping. Project roll-out would involve both installation of software and hardware at client sites, as well as installation and staff training at the large, centrally located Client Services organization. Executive Management needed to decide whether to reorganize this very expensive effort or cancel it. Again, the successful solution depended on establishing an effective cross-functional team (IPT) that necessarily included representatives from the technical teams. The IPT was supported by a newly established Project Management Office (PMO). The PMO integrated the geographically disparate efforts by establishing communication channels, as well as common estimating and scheduling practices. The PMO also instituted monthly critical metrics reports to show the IPT bottlenecks and inefficiencies across the project, from development efforts to Client Services set-up to Payroll technical support.<br />
There are far more examples of the lack of systems engineering practices in EIT projects than in their successful use (unfortunately, this seems also to be true in lots of software projects outside of EIT). Systems Engineering provides a holistic discipline for integrating and managing the contributions of all of the roles needed to provide EIT products and services. It ensures that a single perspective does not dominate outcomes.<br />
==Key External Models of EIT Organizational Capability and Maturity==<br />
Because EIT is critical to businesses globally, considerable effort has gone into establishing universal frameworks for EIT skills, along with definitions of levels of capability of each skill. In addition, at least 2 models have been developed for evaluating the organizational performance of EIT. The effectiveness of systems engineering is key to the effectiveness of the EIT organization.<br />
===IT-CMF: IT-Capability Maturity Framework=== <br />
The IT-CMF had its origin in a quality improvement effort at Intel Labs Europe in Ireland. Its intent, as described at the <br />
[https://cio-wiki.org/wiki/IT_Capability_Maturity_Framework_(IT-CMF) CIO Index website] was to quantify and demonstrate the true value impact of IT. IT-CMF is used to measure, develop, and monitor an organization’s EIT capability maturity. It consists of 35 EIT management capabilities organized into four macro capabilities: managing EIT like a business; managing the EIT budget; managing the EIT capability; and managing EIT for business value. Its 35 critical capabilities (CCs) are [http://eitbokwiki.org/Enterprise_IT_Maturity_Assessment described] as “A defined EIT management domain that helps mobilize and deploy EIT-based resources to effect a desired end, often in combination with other resources and capabilities”. <br />
===CMMI: Capability Maturity Model Integration (US)===<br />
The CMMI had its origin in 1987 in a model requested by the U.S. Department of Defense for determining the capability maturity of contractor software development organizations. This became the Capability Maturity Model (CMM). Since then, it has been expanded into a set of Capability Maturity Models, all based on five levels of demonstrably increasing maturity as measured by organization performance. That set was then integrated and became the CMMI. The CMMI set addresses [https://cmmiinstitute.com/dev Development], [https://cmmiinstitute.com/svc Services], [https://cmmiinstitute.com/sm Supplier Management], [https://cmmiinstitute.com/pm People Management], and [https://cmmiinstitute.com/dm Data Management].<br />
===SFIA: Skills Framework for the information Age (Europe, Canada and US)===<br />
The SFIA Framework has been downloaded and used by organizations and individuals in nearly 180 countries. It can be downloaded for free at [https://www.sfia-online.org]. It identifies 97 professional skills across EIT and supporting areas with seven levels of responsibility, which provide generic levels of responsibility, taking into account reflect experience and competency. These describe the behaviors, values, knowledge, and characteristics that an individual should have in order to be considered competent at a particular level.<br />
===E-CF: European Competency Framework (EU)===<br />
The ECF was the first sector-specific implementation of the European Qualifications Framework (EQF). The European Norm (EN) 16234-1 European e-Competence Framework (e-CF) provides a reference of 41 competences as applied at the Information and Communication Technology (ICT) workplace, using a common European reference for competences, skills, knowledge and proficiency levels. The E-CF Explorer web tool is available [https://ecfexplorer.itprofessionalism.org/ online].<br />
===I Competency Dictionary: EIT skills as Defined by METI/ IPA (Japan)===<br />
The Japanese government’s Information-Technology Promotion Agency (IPA), established by the Ministry of Economy, Trade and Industry (METI) developed the ”I Competency Dictionary” (iCD) to support the IT Engineers Examination. It underlies the METI/IPA Skills Standards for IT Professionals, abbreviated as ITSS, established in 2002. ITSS organizes skills within the information services industry into 11 job categories and 35 specialty fields. In each field, there are seven levels of competence based on individual experience and ability to perform. One appealing feature of ITSS is that this standard allows engineers to draw roadmaps for their own futures and career advancement (Career Path). Approximately 90% of large enterprises and over 60% of SMEs in Japan have introduced or are considering using ITSS. Information in English is available at https://www.ipa.go.jp/english/humandev/forth.html.<br />
===ITIL: Information Technology Infrastructure Library===<br />
According to ITLIlibrary.org, the ITIL Open Guide website, “The Information Technology Infrastructure Library (ITIL) defines the organisational structure and skill requirements of an information technology organisation and a set of standard operational management procedures and practices to allow the organisation to manage an IT operation and associated infrastructure. … The [https://www.itlibrary.org/ “library”] itself continues to evolve. This comprises five distinct areas: <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Strategy ITIL Service Strategy]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Design ITIL Service Design]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Transition ITIL Service Transition]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Operation ITIL Service Operation]; and <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Continual_Service_Improvement ITIL Continual Service Improvement].”<br />
It originally grew out of a British government sponsored effort to regularize IT Service Management (ITSM). <br />
==References==<br />
===Works Cited===<br />
Fong, E.N. and A.H. Goldfine. 1989. ''Information Management Directions: The Integration Challenge. '' National Institute of Standards and Technology (NIST) Special Publication 500-167, September 1989. https://csrc.nist.rip/library/NIST%20SP%20500-167.pdf <br />
<br />
Hammer, M., T.H. Davenport and J. Champy. 1986. ''Dispersion and Interconnection: Approaches to Distributed Systems Architecture'', Cambridge, MA: CSC Index Inc. and Hammer and Company, Inc. (June 1986). Available as: https://www.globalaea.org/general/custom.asp?page=Resources <br />
<br />
Hilliard, R. 2015. “Lessons from the fundamental unity of architecting”. ''Software Engineering in the Systems Context'', editors: Ivar Jacobson and Harold 'Bud' Lawson.<br />
<br />
Hofmeister, C. et al. 2007. “A general model of software architecture design derived from five industrial approaches”. ''The Journal of Systems and Software'' 80(1). <br />
<br />
ISO/IEC 25010:2011 ''Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models'', 4.2.3.2.<br />
<br />
ISO/IEC/IEEE 42010 Users Group. ''Survey of Architecture Frameworks'' Available as: http://www.iso-architecture.org/42010/afs/<br />
<br />
ISO/IEC/IEEE. 2011. ISO/IEC/IEEE 42010:2011, ''Systems and software engineering — Architecture description. ''<br />
<br />
PMI. 2013. ''Software Extension to PMBOK® Guide – Fifth Edition. '' Newtown Square, PA, USA: Project Management Institute (PMI). Available as: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/software-extension-5th-edition.<br />
<br />
Rivera, R. 2013. “The PRISM Architecture Framework – Was it the Very First Enterprise Architecture Framework?” ''Journal of Enterprise Architecture'', November 2013<br />
<br />
Zachman, J. 1987. “A Framework for Information Systems Architecture”. ''IBM Systems Journal'', pp454-470, 1987 <br />
<br />
===Primary References===<br />
IEEE Computer Society. ''Enterprise IT Body of Knowledge''. Available: http://eitbokwiki.org<br />
<br />
=-=Additional References===<br />
IT Capability Maturity Framework (IT-CMF): The Body of Knowledge Guide. 2015. Editors. Martin Curley, Jim Kenneally, Marian Carcary. Van Haren Publishing.<br />
<br />
Lessons from Systems Engineering Failures: Determining Why Systems Fail, The State of Systems Engineering Education, and Building an Evidence-Based Network to Help Systems Engineers Identify and Fix Problems on Complex Projects, Diane Constance Aloisio, December 2018.<br />
<br />
===International Standards Guiding EIT===<br />
ANSI/AIAA. 2012. ''ANSI/AIAA Guide to the Preparation of Operational Concept Documents. '' ANSI/AIAA G-043A-2012e.<br />
<br />
IEEE 2012 Std 828™-2012, ''IEEE Standard for Configuration Management in Systems and Software Engineering. ''<br />
<br />
ISO 10004:2012, Quality management—Customer satisfaction—Guidelines for monitoring and measuring<br />
<br />
ISO 10007:2003, Quality management systems—Guidelines for configuration management<br />
<br />
ISO 18238:2015, Space systems—Closed loop problem solving management<br />
<br />
ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models<br />
<br />
ISO/IEC 16350:2015, Information technology—Systems and software engineering—Application management<br />
<br />
ISO/IEC 19770-1:2012, Information technology—Software asset management—Part 1: Processes and tiered assessment of conformance<br />
<br />
ISO/IEC 20000-1:2011, (IEEE Std 20000-1:2013) Information technology—Service management—Part 1: Service management system requirements<br />
<br />
ISO/IEC 20000–2:2012, Information technology—Service management—Part 2: Guidance on the application of service management systems<br />
<br />
ISO/IEC TR 20000–10:2015, Information technology—Service management—Part 10: Concepts and terminology<br />
<br />
ISO/IEC TR 20000–11:2015, Information technology—Service management—Part 11: Guidance on the relationship between ISO/IEC 20000-1:2011 and related frameworks: ITIL®<br />
<br />
ISO/IEC TR 20000-12—Information technology—IT Service management—Part 12: Guidance on the relationship between ISO/IEC 20000-1:2011 and service management frameworks: CMMI-SVC®<br />
<br />
ISO/IEC/IEEE 14764-2006, Software Engineering—Software Lifecycle Processes—Maintenance<br />
<br />
ISO/IEC 15939:2007, Systems and software engineering—Measurement process<br />
<br />
ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description <br />
<br />
<br />
----<br />
<center>[[ Systems Engineering and Economics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Quality Attributes|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Enterprise_IT&diff=66927
Systems Engineering and Enterprise IT
2023-04-24T06:01:04Z
<p>Mhaas: </p>
<hr />
<div>----<br />
'''''Lead Authors:''''' Chuck Walrad and Richard Hilliard<br />
----<br />
This article forms part of the [[Related Disciplines]] knowledge area (KA). It discusses enterprise IT, building upon the concepts and practices of Systems Engineering presented elsewhere in the SEBOK. Systems Engineering is integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of ''engineered technical systems''. <br />
<br />
== Enterprise IT Introduction==<br />
Although it had its origin in the need to improve success rates in U.S. Government outsourcing of technical systems, Systems Engineering is also integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of [https://www.incose.org/about-systems-engineering/system-and-se-definition/systems-engineering-definition#ENGINEERED_SYSTEM engineered technical systems].<br />
Examples of EIT systems include enterprise resource planning, supply chain management and customer relationship management systems, accounting, finance, inventory and order management, marketing, planning, purchasing, and sales.<br />
In the late 1980s and throughout the 1990s, EIT organizations became increasingly aware that the success rates of IT projects were very low, and that their enterprise customers were increasingly unhappy with their EIT investments. The Standish Group sought to understand what was going on. Their findings were presented in the [https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf Chaos Report] (1994):<br />
The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable but could easily be in the trillions of dollars.<br />
As a result, commercial IT organizations, through the auspicious parallel emergence of the Total Quality Management movement and the increasingly widespread development of application development methodologies (ADM) by IT management consulting firms, recognized the need for the principles of Systems Engineering and cross-functional teams (Integrated Product Teams [https://www.sebokwiki.org/wiki/Integrated_Product_Team_(IPT)_(glossary)]. It should be noted that there is considerable overlap today between what constitutes Systems Engineering and what constitutes [[Project and Portfolio Management|Relationships between Systems Engineering and Project Management]] (see [https://www.pmi.org/learning/library/bridging-gap-program-management-systems-engineering-6213 PMI]). This article does not attempt to resolve this issue. Note that the “[[Related Business Activities|following business management activities]] can be ''supported'' by enterprise systems engineering (ESE) activities” [emphasis added]: <br />
* mission and strategic planning,<br />
* business processes and information Management,<br />
* performance management,<br />
* portfolio management,<br />
* resource allocation and budgeting, and<br />
* program and project management.<br />
Note that these same areas have been designated as being supported by Project Management Offices. However, since a key difference between project management and systems engineering has been identified as the requirement that the latter includes technical expertise in the product/system of concern, focus should be on systems engineering and integrated product teams (IPTs). <br />
With IPTs, each product is shepherded from concept through delivery and support to retirement by a cross-functional team that includes representatives from each area of responsibility, such as customer requirements development, design and development, test, configuration management, release engineering, delivery, and support.<br />
As enterprises have come to depend more and more on technology to perform effectively, Enterprise IT organizations have matured, often due to the influence of IT consulting firms that make it their business to keep abreast of best practices.<br />
<br />
== EIT Concepts ==<br />
This knowledge area (KA) discusses enterprise IT, building upon the concepts elucidated in the IEEE/ACM ''[http://eitbokwiki.org EITBOK Guide to the Enterprise Information Technology Body of Knowledge]'' and general concepts of Systems Engineering elsewhere in SEBOK. <br />
An enterprise may be viewed from various perspectives: such as a system or a [[system of systems (SoS)|Enterprise Systems Engineering]]:<br />
* system-like enterprise: enterprises, like other systems, may have a tight coupling, single-executive function; <br />
* system of systems-like enterprise: may be a loosely coupled group of organizations with blurred boundaries and (yet) with (some) shared outcomes.<br />
The choice of perspective may vary with many factors: the enterprise itself, the mission or purpose, or the particular engineering task at hand. We can view an enterprise as a system with inputs and outputs in relation to the outside world, or a system of systems interacting through their individual inputs and outputs. <br />
An enterprise usually involves one (or more) organization(s) but need not be identified with the organization. As the scope of human and organizational participants of the enterprise widen, there may be no single point of control. For example, an ''extended enterprise'' could include a company, its suppliers and customers.<br />
Whatever perspective (system-like, SoS-like, other) is taken there are [[key ingredients|Enterprise Systems Engineering Background]] of any enterprise: capabilities, individual (competencies) and the organizational design. [[Capabilities|Enterprise Capability Management]] can be further categorized: “There are three different kinds of capability: organizational capability, system capability, and operational capability.” These capabilities determine what the enterprise is able to produce which may be external offerings or internal mechanisms. Operational capabilities create services and/or products which in turn produce value as determined by stakeholders. The capabilities of an enterprise are realized through [[Enterprise Systems Engineering Background|various enterprise elements]], including: “hardware, software, personnel, facilities, data, materials, techniques, and even services”. which include “soft” items, like people, processes, principles, policies, practices, organizations, doctrine, theories, and beliefs.<br />
EIT capabilities exist through lifecycles spanning from creation through eventual replacement and disposal. ''Life cycle models'' are schemes to aid in the understanding, design, planning and management of the capability of interest. <br />
“A life cycle for a system generally consists of a series of stages regulated by a set of management decisions which confirm that the system is mature enough to leave one stage and enter another.” Basic life cycle terms and concepts are discussed in [[System Lifecycle Approaches]]. Some typical life cycles are discussed in [[System Lifecycle Models]].<br />
A life cycle-based approach can be deployed across the several levels and used to manage evolution. These levels are:<br />
* the enterprise itself,<br />
* the processes and organizations constituting the enterprise,<br />
* the systems enabling the capabilities, services or products provided. <br />
It is important to distinguish between ''product'' and ''project'' lifecycle models. A product’s life cycle extends from its initial concept approval, through development and distribution, to its retirement. This is the cycle that is managed within an Enterprise IT organization, since EIT must manage the hardware or software product from its introduction, in the case of acquired capabilities, or from its concept approval and development, in the case of capabilities it builds, through its deployment, maintenance and eventual retirement (withdrawal). Each of these stages is usually managed as a project or a series of projects.<br />
However, most discussions of life cycles within software and systems discussions focus on ''project'' life cycles. See, for example, the ''Software Extension to PMBOK Guide'' (PMI 2013).<br />
==System of Systems Context in EIT==<br />
“Enterprise IT” (EIT) is used both to refer to the technology organization/business unit within the enterprise and to the enterprise’s information technology systems. In this article, we use EIT to refer to the technology systems. When referring to the organization, we use the phrase “Enterprise IT organization” or EIT organization. <br />
Enterprise IT organizations are responsible for complex socio-technical systems. Socio-technical systems in a business context (thus, EIT) contain technical elements (software, hardware, networks, storage, databases, etc.) but they also contain essential human components and necessary business processes. As covered in [[Introduction to Systems Engineering Fundamentals]], they exist in an engineered System Context that is a set of system component interrelationships within a real-world environment:<br />
This includes where problems come from and how they are defined, how we identify and select candidate solutions, how to balance technology and human elements in the wider solution context, how to manage the complex organizational systems needed to develop new solutions, and how developed solutions are used, sustained and disposed of. … Systems Engineering should consider the full Engineered System Context so that the necessary understanding can be reached and the right systems engineering decisions can be made. <br />
Socio-technical systems also have the following key characteristics: ''Openness'' in that they strongly interact with their environments, and ''unfinished'' in that they evolve over time.<br />
A complex of EIT systems is essential to the successful functioning of the humans in the enterprise. They rely on EIT’s technology for communication, for paying employees, for people management, for business measurement, and often for managing supply chains. Thus, “EIT needs to be viewed as a strategic partner to all the other functions and business units within an enterprise. This means that the results produced by EIT along with its effectiveness and efficiency are all critically important to the success of the enterprise.” [http://eitbokwiki.org/What_is_the_Enterprise_Perspective%3F]<br />
To accomplish this mission, the EIT organization builds and acquires new systems or system components, integrates them into the mega System of Systems, and maintains the integrity and interoperability of the individual components, but also the integrity of the entire complex of systems. In addition, security and performance levels must be achieved, benchmarked and maintained or improved.<br />
==Major concerns of the EIT Organization==<br />
The [http://eitbokwiki.org ''Enterprise IT Body of Knowledge''] provides a good deal of information about these major concerns, which we will not replicate here. Rather, links to the relevant areas are provided. The EITBOK demonstrates how, in providing technology systems and services to the enterprise, the EIT organization must skillfully manage such concerns as the following.<br />
<br />
===Enterprise Architecture===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Enterprise_Architecture Enterprise Architecture] for additional information. ''<br />
[http://eitbokwiki.org/Glossary#ea ''Enterprise architecture''] (EA) is the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. EA applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their organization's strategies. Enterprise architecture builds upon many of the concepts and practices of [[System Architecture Definition|systems architecture]] and also software architecture [https://www.sebokwiki.org/wiki/System_Architecture_Definition].<br />
This section will discuss Enterprise Architecture from the perspective of key [[Principles of Systems Thinking]], designated in this article with '''''bold italics'''''. There are many commonalities in architecture whether one is architecture systems, software or the enterprise [Unity]. In this article we highlight both commonalities and differences between Enterprise Architecture and Systems Architecture. <br />
Architecture takes place at the juncture of design problems and their solutions. Design problems rarely arrive fully formulated or “hatched” for the architect; much of the architecture effort is to analyze or formulate the problems to be solved. Often this involves negotiation both within the enterprise and with outside stakeholders. Possible solutions are limited by resources and schedule and therefore often must also be negotiated.<br />
A dominant principle of Enterprise Architecture is '''''separation of concerns''''' (SoC). This is due to the complexity of enterprises, with many forces acting upon them; the many technologies and disciplines involved in their creation and day-to-day operations; and due to the diversity of stakeholders involved in the enterprise (see [[EIT Roles]]). <br />
An application of SoC is the '''''boundary''''' principle which is crucial to separate what is “inside” the enterprise from what is “outside”. While the former is often under the enterprise’s control, the latter is often beyond its control. <br />
For some systems, determining the boundary is a key decision, subject to many possibilities and consequences. This is perhaps less the case for enterprises whose bounds are determined by the extent of organizations, regulations, supply chains or other criteria. Within an established boundary, the '''''holism''''' principle applies: to treat the enterprise as a unified whole, and, in particular, with respect to the '''''interaction''''' of the enterprise with its ''environment''—including stakeholders, other enterprises and systems. From an enterprise IT perspective, an enterprise is a ''system of systems. '' SoC offers a way to focus on the constituent systems in terms of their interconnections to one another to form the enterprise.<br />
Another useful application of SoC is to apply the principle of '''''multiple views''''' to depict the architecture of the enterprise in different ways to address the diverse interests (i.e., ''concerns'') of an enterprise’s various stakeholders. Each ''architecture view'' presents a specific perspective on the enterprise. To be understandable to its audiences (those various stakeholders), each view should follow the conventions of its ''architecture viewpoint'' (ISO/IEC/IEEE 42010 2011). Just as a map should have a legend, each view should have a documented viewpoint providing a prescribed set of conventions for looking at the enterprise through the resulting view. A viewpoint definition serves as a contract between the architect and stakeholders on ''how'' a selected set of concerns are to be addressed. Each viewpoint allows the architect to consider the enterprise in terms of various kinds of elements and relations among them and to present that view to those “concerned” stakeholders. Dominating concerns in enterprise architecture include interoperability, quality of systems and services, operations, managing change, and alignment with the enterprise’s mission, market, and technology. Via the principle of '''''dualism''''', we recognize that some viewpoints are paired, such as with process/data duality. Another pervasive duality in the enterprise is of people/technology in terms of what capabilities are automated and which are performed by people.<br />
In support of enterprise architecture, there are numerous ''enterprise architecture frameworks'' each providing a pre-defined, integrated set of viewpoints to frame typical, recurring concerns (ISO/IEC/IEEE 42010 Users Group 2022). The earliest recorded framework was (Hammer et al. 1986), developed in the mid-1980s in response to growing availability of distributed computing to the enterprise (Rivera 2013). In the late 1980s, US NIST created its Enterprise Architecture Model as a guide for US federal departments to organize their IT offerings (Fong and Goldfine 1989). NIST’s 5-layer model remains influential today. Despite never using the term “enterprise,” Zachman’s information systems architecture has had a major influence on how subsequent frameworks have been organized and depicted using grids or cubes. Later frameworks have evolved in response to emerging concepts, such as the move from client-server to service-oriented applications, as in the OASIS SOA Reference Model and its associated framework. The 1990s saw a proliferation of frameworks for defense enterprises including US DODAF, UK MODAF, NATO’s NAF and led to successors such as OMG’s UAF.<br />
Yet another application of '''''separation of concerns''''' is distinguishing today’s needs versus facilitating future needs; balancing '''''stability/change''''' and highlighting the temporal planning aspect of architecture of the enterprise. In concert with applying SOC, the architect uses the principle of '''''abstraction''''' to “forget” some details of the subject and thus focus on essentials. Just as SoC is a way of taking things apart, '''''abstraction''''' is a way of unifying or putting like things together through generalization. These two principles are perhaps the most central to architecture. SoC and abstraction work together: SoC picks out subjects and abstraction helps architects to focus upon the essentials of each subject. <br />
Returning to the '''''boundary''''' and '''''holism''''' principles, the enterprise architect applies these recursively. As architecting proceeds, the internal details of the enterprise become known in terms of '''''interaction''''' among its parts and other '''''relations'''''. Again, '''''multiple views''''' are used to factor specific '''''relations'''''into distinct views. Typical relations include Causality, Dependency, Client-Server, and Input-Output. <br />
There are a variety of ways to structure the enterprise based upon stakeholder needs, mission or charter, technologies or capabilities already in place. Among these are structuring principles including: <br />
* '''''Modularity''''' (separate and group capabilities into modules by commonalities); <br />
* '''''Network''''' (modules are linked together); <br />
* '''''Encapsulation''''' (separating architecture modules use from how they are implemented); <br />
* '''''Layer Hierarchy''''' (separation through gradual refinement); <br />
* ''''' Regularity''''' (uniformity of interactions, of structure within layer, within network). <br />
* ''''' Similarity/Difference''''' (recognizing the limits of Regularity)<br />
A simple pattern for architecture has been defined (Hofmeister ''et al. '' 2007). Its elements are Analysis, Synthesis and Evaluation. See Figure 1 below. <br />
''Architecture Analysis'' formulates architecturally-significant requirements (ASRs)—those requirements which influence an enterprise’s architecture. Architecture analysis is based on identified concerns and other information based on understanding the enterprise’s environment, known requirements, stakeholder needs and any constraints. ASRs reflect the “design problems” that the architecture must solve. In many cases, negotiations take place to modify incoming needs, requirements and expectations to make solutions possible. The result of this activity takes the form of ASRs, including architecture principles and initial enterprise-wide decisions.<br />
''Architecture Synthesis'' develops candidate solutions in response to the concerns and ASRs. During Synthesis the architect works out the details of solutions to the identified design problems, tradeoff and interactions between them which are likely to generate further design problems. Synthesis elaborates the ASRs, principles and initial decisions into more detailed solution elements. The principle of ''''' EQUIFINALITY''''' reminds us that for many stable situations (i.e., states of the enterprise), there are many ways to reach those states.<br />
''Architecture Evaluation'' validates whether chosen solutions satisfy ASRs or whether rework is needed (ISO/IEC/IEEE 42030 2019).<br />
Applying the principles discussed above is pervasive in enacting the Analysis–Synthesis–Evaluation pattern iteratively. <br />
<br />
<br />
Figure 1 A pattern for Architecture<br />
While there are many commonalities among EIT, systems and software architectures, Figure 2 addresses the relationships ''between'' them. Viewing an enterprise as a system, the EIT architecture governs the fundamental IT decisions of the enterprise. That enterprise might be extended to “outsiders” such as vendors, suppliers and perhaps customers. Depending upon the enterprise, the ''governs'' relationship may entail very strict rules or loose guidance. <br />
Within the enterprise, the ecosystem of systems, applications and data may be viewed as a system of systems. The EIT Architecture constrains the architectures governing individual systems, applications and data stores within the enterprise, so that these are able to interoperate and otherwise “play nicely” together.<br />
<br />
Figure 2 Relating Enterprise IT, Systems and Software Architecture<br />
===Strategy and Governance===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance] for additional information. ''<br />
<blockquote><br />
[http://eitbokwiki.org/Glossary#eit Enterprise information technology] (EIT) governance is the established process of defining the strategy for the EIT organization and overseeing its execution to achieve enterprise goals. Strategic planning translates the larger enterprise’s goals into EIT goals and defines what EIT must do to achieve those goals. This effort then communicates this hierarchy of goals: EIT goals as well as how they support the enterprise’s goals. EIT governance drives needed changes to achieve those goals, while maintaining agreed levels of operation. Taking into account various perspectives (such as financial, historical, environmental, and future projections), a strategic plan is a roadmap for action and change, both vertically and horizontally, across the EIT organization. The EIT organization’s strategic plans are based on the enterprise’s strategic plans, focusing on EIT’s role in them; EIT governance provides a monitoring and control framework to achieve strategic goals and objectives. Thus, EIT governance is essential for achieving the EIT strategy and goals..<br />
-[http://eitbokwiki.org/Strategy_and_Governance EITBOK wiki]<br />
</blockquote><br />
<br />
The principle of ''''' PARSIMONY''''' applies here, too (see [[Principles of Systems Thinking]]). These principles will be designated in this article with '''''bold italics'''''. For example, the simplest possible measurement and reporting systems are most likely to be used and not corrupted. Similarly, the EIT organizational structure should be straightforward and easy to traverse so that staff can communicate and problem-solve in teams.<br />
In governing the EIT organization to meet its dual goals of satisfying its customers and meeting its budget and schedule commitments, EIT management encounters the difficulty of managing in the face of '''''dualism''''', “ensuring a constant dynamic balance often through a cyclic dominance of one element and then the other”. The most obvious instance of handling ''''' dualism''''' in EIT is the trade-off between budget, project prioritization and features within projects.<br />
===Change===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Change_Initiatives Change Initiatives] for more information. ''<br />
There are two levels of change management discussed in the EITBOK: organizational change management and changes to the IT organization’s assets, whether they be software, hardware, or telecommunications systems.<br />
In the larger sense, the introduction of new systems and services often also requires changes in people’s jobs and in the processes used to accomplish those jobs. Such efforts are intended to increase business value. Such changes require change initiatives because they involve guiding a mixture of stakeholders through the change process. This is one aspect of [http://eitbokwiki.org/Change_Initiatives change management].<br />
Change also occurs when existing systems or services must be updated to meet new needs. Depending on the scope of the proposed changes, a change initiative may be required in this situation, too. At any rate, a change request process must be initiated and tracked to disposition (deferral, rejection, or implementation). Changes also come about as a result of defect reports. In such cases, the defect report must be tracked throughout the report’s life cycle, to disposition (deferral, rejection, or implementation).<br />
These latter types of change management are discussed in detail in the EITBOK’s section on [http://eitbokwiki.org/Operations_and_Support Operations and Support].<br />
===Interoperability of Component Systems===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Interoperability interoperability] for more information. ''<br />
As explained in the [http://eitbokwiki.org/Interoperability#One EITBOK], ''interoperability'' means “the ability of systems (including organizations) to exchange and use exchanged information without knowledge of the characteristics or inner workings of the collaborating systems (or organizations).” This definition is based on an ISO definition: “degree to which two or more systems, products, or components can exchange information and use the information that has been exchanged.” (ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models, 4.2.3.2. ) Note that this definition includes hardware components as well as software systems and the organizations in which they are used.<br />
Because technology changes so rapidly, and organizations themselves are frequently changing, achieving and maintaining interoperability is crucial. It is one of the main reasons that providing IT services is difficult and how it differs from engineering and delivering finished products, whether off-the-shelf products or bespoke systems.<br />
===Security of Systems and Data===<br />
<blockquote><br />
There are only two types of companies: those that have been hacked, and those that will be.<br />
-FBI Director Robert Mueller, October 2012<br />
</blockquote><br />
<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Security security] for additional information. ''<br />
While there are many definitions for security, most include the three dimensions of confidentiality, integrity, and availability (sometimes referred to as the [http://eitbokwiki.org/Glossary#ciatriad CIA triad]). As such, the primary goal of EIT security is to preserve the confidentiality, integrity, and availability of information and information systems. <br />
The principles behind an organization’s [http://eitbokwiki.org/Glossary#isms information security management system] (ISMS) should be to design, implement, and maintain a coherent set of policies, processes, and systems that keep the risks associated with its information assets at a tolerable level, and yet, manage the cost and inconvenience of said risk management. As such, the goals of EIT security are to:<br />
* Always understand the current risk tolerance of the enterprise with respect to information and device security.<br />
* Understand the security threats and potential damages to information, devices, and individuals.<br />
* Create and follow policies and procedures that keep cyberattack risk and damages at or below a tolerable level.<br />
* Effectively and efficiently detect and deal with<br />
[http://eitbokwiki.org/Security#One cyberattack incidents].<br />
Ensuring security in EIT has been made even more pressing and more difficult by the proliferation of mobile devices in enterprises and their ever-increasing use to conduct business. Increasingly, personal devices (Bring Your Own Device – BYOD) are used, accessing both corporate networks and public networks. The cost of [https://www.checkpoint.com/downloads/products/check-point-mobile-security-survey-report2013.pdf mobile security incidents] very easily can outweigh the cost of the mobile device itself. <br />
==Quality of Systems and Services==<br />
The Enterprise ''Information'' Technology organization has, since its origins, had as its primary responsibility the timely provision of information to the larger organization. The information is expected to be not only timely, but also accurate and relevant. While the EIT organization itself may not be responsible for creating the data, it is responsible for the physical and logical validity and [https://simplicable.com/new/data-integrity-vs-data-quality integrity of the data] that is used to construct information. It is for this reason that defining and using appropriate processes is essential to ensure high-quality operation, including the development or acquisition, implementation and integration of new or changed capabilities.<br />
The EITBoK details the quality concepts of<br />
* How to approach measuring [http://eitbokwiki.org/Quality#Measuring_Quality Quality]<br />
* The importance of Quality in [http://eitbokwiki.org/Quality#Requirements_Management Requirements Management]<br />
* Understanding an organization’s [http://eitbokwiki.org/Quality#Quality_Capability Quality Capability]<br />
* The differences between [http://eitbokwiki.org/Quality#QMS_and_QC_vs._QA QMS, QC and QA]<br />
* Cost of Quality in [http://eitbokwiki.org/Quality#Technical_Debt_and_the_Cost_of_Rework Technical Debt and the Cost of Rework]<br />
==Disaster Preparedness==<br />
<br />
As explained in the [http://eitbokwiki.org/Disaster_Preparedness EITBOK], disaster preparedness and [http://eitbokwiki.org/Glossary#dr disaster recovery] (DR) support business-continuity planning and include planning for EIT resiliency, as well as recovery from adversity, so that critical business services affected are restored to a satisfactory working state within an [http://eitbokwiki.org/Glossary#acceptable acceptable] timeframe after an event.<br />
The EITBoK devotes a chapter to how the EIT organization and its parent must plan in advance for how it will provide sufficient organizational resilience to recover from disasters and return to normal operation as rapidly as possible.<br />
It provides the following examples of disasters and service interruptions that could occur and should be considered in prevention and recovery planning:<br />
These are examples of disasters:<br />
* Natural disaster affecting datacenters or EIT service operations (flood, fire, earthquake, wind)<br />
* Security breach resulting in a disaster (destruction of data, admin password changes, virus/malware installation, sabotage)<br />
* Usage error (accidental deletion, unplug/turn off system resulting in corruption)<br />
* Utility failure affecting datacenters (loss of power even after UPS)<br />
* Vendor failure (cloud provider security failure, oil spill)<br />
* Staffing issue (employment dispute/walkout, epidemic)<br />
These are examples of unpreparedness:<br />
* Requiring use of computers or printers when power is out<br />
* Requiring use of Internet when power or connectivity is out<br />
* Single point of knowledge/control for administration access<br />
* Lack of offsite backup storage<br />
* Lack of working restoration from backups<br />
* Lack of failover datacenters in separate locations<br />
* Undocumented or out-of-date documentation for system interfaces<br />
*Requiring use of phones that are out of power<br />
* Lack of designation of leaders in restoration efforts (who is in charge of restoring service and they know they are in charge)<br />
* In general, no cohesive, comprehensive EIT service restoration plan<br />
==Operations and Support of Delivered Systems and Services==<br />
[http://eitbokwiki.org/Operations_and_Support Operations and support activities] focus on maintaining an operation normal state in EIT environments, meaning that systems and processes execute according to expectations, with no surprises to users. This desired normal state requires the careful management of EIT assets and services via Operations, as well as of users via Support.<br />
Normal states can be disrupted either by the expected and planned transition of an asset, or by an unexpected event, be it as large as a disaster or by the discovery of a system defect. In the former case, the Disaster Recovery Plan is executed; in the latter, incident management kicks in when a system halts, or problem management is exercised when an operational system is not functioning as expected. The processes needed to ensure effective application of these complex functions is detailed in the [http://eitbokwiki.org/Operations_and_Support#Guiding_Principles Operations and Support Knowledge Area] within the EITBOK. <br />
ISO/IEC/IEEE 20000 may be used by any organization to develop and manage EIT operations, along with the current version of [https://www.servicenow.com ITIL].<br />
ITIL for many is the tool of choice for the operations and infrastructure side of IT, particularly for IT services. <br />
==Ethics==<br />
See the EITBOK’s section on [http://eitbokwiki.org/Ethics ethics] for additional information.<br />
Both the IEEE and ACM require their members to adhere to Codes of Ethics. See the [https://www.ieee.org/about/corporate/governance/p7-8.html IEEE Code of Ethics] and [https://www.acm.org/code-of-ethics ACM Code of Ethics and Professional Conduct]. Both of these can be downloaded freely. In addition, the IEEE Computer Society and the ACM worked together on the [https://dl.acm.org/action/downloadSupplement?doi=10.1145%2F265684.265699&file=acm-se-code-of-ethics.html Software Engineering Code of Ethics] (also available [https://dl.acm.org/doi/10.1145/265684.265699 here]).<br />
The organization should create an easily accessible Code of Ethics:<br />
* Ethical assertions should be documented and socialized in EIT in the form of a Code of Ethics, tied to the overall business code of ethics, and signed off by all staff so that violations can be cause for reprimand or dismissal.<br />
* Vendors should be held to similar ethical standards.<br />
* Lists of employees who have signed off on the Code of Ethics are maintained by EIT governance.<br />
The EITBOK has identified EIT ethical topics that include:<br />
* Those actions and decisions that may be illegal<br />
* Consideration of the social impact of the work at hand—if it will cause harm<br />
* Alignment of business and EIT strategies and policies to an ethical standard<br />
* Incorporation of the ideals of professionalism<br />
* Adherence to applicable regulatory intent<br />
* Protection for whistle blowers<br />
Areas to specifically highlight:<br />
* Activities that interfere with or corrupt the proper function of computers, applications and systems<br />
* Activities that interfere with digital privacy or intellectual rights of others<br />
* Respect for confidentiality, privacy, permissions, and access rights<br />
* Inappropriate bias (skewing) of analysis and reporting<br />
* Inaction in the face of likely ethics violations<br />
==EIT Roles==<br />
Several roles play a part in accomplishing the EIT organization’s mission. Just as a systems engineer can play several roles in a given project, so might several people in an EIT project combine to fulfill the systems engineering function. <br />
The function of EIT systems engineering is to orchestrate systems development, delivery and operation such that the larger organization achieves favorable outcomes in complex environments. Unlike systems projects that are built for known problems, EIT systems may change in unpredictable ways. A primary concern focuses on how quickly systems adapt to change. This entails a type of resiliency based on skills in establishing options and alternative solutions as well as strategies tailored to the volatility of changing needs and available technologies. It also requires expertise in assuring that systems quality is assured from the start.<br />
Different countries, geographic areas and organizations do not always use the same terminology to reference the functions that the roles contributing to systems engineering perform. The following section will provide information about some major international models for defining EIT skills and capabilities. Generally, though, the necessary roles across the product life cycle include these:<br />
* Business Sponsor/Champion<br />
* Enterprise Architect<br />
* Systems Engineer<br />
* Financial Manager<br />
* Application Architect<br />
* Business Analyst and/or Process Analyst<br />
* Data Analyst and/or Data Architect<br />
* Software Engineer and/or Programmer<br />
* Quality Assurance & Testing<br />
* Network Engineer<br />
* Telecoms Engineer<br />
* Integration Expert <br />
* Transition to Operations Manager<br />
* Release Manager<br />
* Availability Manager<br />
* Capacity Manager<br />
* Change Manager<br />
* Configuration Manager<br />
* EIT Operations Manager<br />
* Incident Management<br />
* Problem Manager<br />
* Service Level Manager<br />
* Database Administrator<br />
* Network Manager<br />
* Product Manager<br />
System engineering activities orchestrate the work of these roles so that they function together, rather than in silos or at cross purposes.<br />
==Examples of Systems Engineering in EIT==<br />
Systems Engineering provides a holistic discipline for integrating and managing the contributions of all roles needed to establish and provide EIT products and services. It ensures that a single perspective does not dominate outcomes; instead, it seeks balance among the many disciplines represented above in creating a consistent product or service that meets the interests and needs of enterprise users (and, perhaps, partners). It boils down to common sense, technical sense, knowing when to ask the right questions, and getting the data to support the answers to those questions. System Engineering achieves this via Systems Engineers. In many instances, though, the SE function is accomplished through Project Management approaches using Integrated Product Teams that include technical experts. Thus, although not specifically calling out a Systems Engineering function, the use of IPTs involved the use of SE practices.<br />
A doctoral dissertation from Purdue University performed a survey and causal analysis of project failures and of accidents(Aloisio, 2018). The results were similar to those found in reviews of IBM consulting projects in the 1990s . The following are examples of Systems Engineering interventions that prevented project failures. Almost all point to the lack of the System Engineering balancing act needed for product delivery.<br />
* A widely used document processing product was undergoing a major upgrade. The new VP of Engineering wanted a project review before committing to a schedule. The review showed that the proposed schedule only considered the development effort and did not give sufficient weight to the voices of the testing and documentation organizations, while the needs of the tech support group had been completely overlooked. By establishing an integrated product management team that included technical expertise, as well as expertise in work breakdown and estimating, a realistic effort was defined and the resulting 9-month schedule was met within 3 weeks.<br />
* A Silicon Valley start-up was depending entirely on an offshore development effort to produce its first product. All senior management was in the U.S. The VP of engineering made monthly visits to the development team. The CEO began to feel uneasy about the team’s ability to deliver on schedule sensing that a lot of finger pointing within the development team itself signaled problems. There was no SE or IPT guiding the project. The VP of Engineering seemed unable to sort things out. A project review showed that the probable delivery date was at least 6 months beyond what the CEO was being told. The project was shut down.<br />
* A major player in Human Resource Management had made commitments to deliver a new product. The project involved more than 100 people across the U.S. The delivery date kept slipping. Project roll-out would involve both installation of software and hardware at client sites, as well as installation and staff training at the large, centrally located Client Services organization. Executive Management needed to decide whether to reorganize this very expensive effort or cancel it. Again, the successful solution depended on establishing an effective cross-functional team (IPT) that necessarily included representatives from the technical teams. The IPT was supported by a newly established Project Management Office (PMO). The PMO integrated the geographically disparate efforts by establishing communication channels, as well as common estimating and scheduling practices. The PMO also instituted monthly critical metrics reports to show the IPT bottlenecks and inefficiencies across the project, from development efforts to Client Services set-up to Payroll technical support.<br />
There are far more examples of the lack of systems engineering practices in EIT projects than in their successful use (unfortunately, this seems also to be true in lots of software projects outside of EIT). Systems Engineering provides a holistic discipline for integrating and managing the contributions of all of the roles needed to provide EIT products and services. It ensures that a single perspective does not dominate outcomes.<br />
==Key External Models of EIT Organizational Capability and Maturity==<br />
Because EIT is critical to businesses globally, considerable effort has gone into establishing universal frameworks for EIT skills, along with definitions of levels of capability of each skill. In addition, at least 2 models have been developed for evaluating the organizational performance of EIT. The effectiveness of systems engineering is key to the effectiveness of the EIT organization.<br />
===IT-CMF: IT-Capability Maturity Framework=== <br />
The IT-CMF had its origin in a quality improvement effort at Intel Labs Europe in Ireland. Its intent, as described at the <br />
[https://cio-wiki.org/wiki/IT_Capability_Maturity_Framework_(IT-CMF) CIO Index website] was to quantify and demonstrate the true value impact of IT. IT-CMF is used to measure, develop, and monitor an organization’s EIT capability maturity. It consists of 35 EIT management capabilities organized into four macro capabilities: managing EIT like a business; managing the EIT budget; managing the EIT capability; and managing EIT for business value. Its 35 critical capabilities (CCs) are [http://eitbokwiki.org/Enterprise_IT_Maturity_Assessment described] as “A defined EIT management domain that helps mobilize and deploy EIT-based resources to effect a desired end, often in combination with other resources and capabilities”. <br />
===CMMI: Capability Maturity Model Integration (US)===<br />
The CMMI had its origin in 1987 in a model requested by the U.S. Department of Defense for determining the capability maturity of contractor software development organizations. This became the Capability Maturity Model (CMM). Since then, it has been expanded into a set of Capability Maturity Models, all based on five levels of demonstrably increasing maturity as measured by organization performance. That set was then integrated and became the CMMI. The CMMI set addresses [https://cmmiinstitute.com/dev Development], [https://cmmiinstitute.com/svc Services], [https://cmmiinstitute.com/sm Supplier Management], [https://cmmiinstitute.com/pm People Management], and [https://cmmiinstitute.com/dm Data Management].<br />
===SFIA: Skills Framework for the information Age (Europe, Canada and US)===<br />
The SFIA Framework has been downloaded and used by organizations and individuals in nearly 180 countries. It can be downloaded for free at [https://www.sfia-online.org]. It identifies 97 professional skills across EIT and supporting areas with seven levels of responsibility, which provide generic levels of responsibility, taking into account reflect experience and competency. These describe the behaviors, values, knowledge, and characteristics that an individual should have in order to be considered competent at a particular level.<br />
===E-CF: European Competency Framework (EU)===<br />
The ECF was the first sector-specific implementation of the European Qualifications Framework (EQF). The European Norm (EN) 16234-1 European e-Competence Framework (e-CF) provides a reference of 41 competences as applied at the Information and Communication Technology (ICT) workplace, using a common European reference for competences, skills, knowledge and proficiency levels. The E-CF Explorer web tool is available [https://ecfexplorer.itprofessionalism.org/ online].<br />
===I Competency Dictionary: EIT skills as Defined by METI/ IPA (Japan)===<br />
The Japanese government’s Information-Technology Promotion Agency (IPA), established by the Ministry of Economy, Trade and Industry (METI) developed the ”I Competency Dictionary” (iCD) to support the IT Engineers Examination. It underlies the METI/IPA Skills Standards for IT Professionals, abbreviated as ITSS, established in 2002. ITSS organizes skills within the information services industry into 11 job categories and 35 specialty fields. In each field, there are seven levels of competence based on individual experience and ability to perform. One appealing feature of ITSS is that this standard allows engineers to draw roadmaps for their own futures and career advancement (Career Path). Approximately 90% of large enterprises and over 60% of SMEs in Japan have introduced or are considering using ITSS. Information in English is available at https://www.ipa.go.jp/english/humandev/forth.html.<br />
===ITIL: Information Technology Infrastructure Library===<br />
According to ITLIlibrary.org, the ITIL Open Guide website, “The Information Technology Infrastructure Library (ITIL) defines the organisational structure and skill requirements of an information technology organisation and a set of standard operational management procedures and practices to allow the organisation to manage an IT operation and associated infrastructure. … The [https://www.itlibrary.org/ “library”] itself continues to evolve. This comprises five distinct areas: <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Strategy ITIL Service Strategy]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Design ITIL Service Design]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Transition ITIL Service Transition]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Operation ITIL Service Operation]; and <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Continual_Service_Improvement ITIL Continual Service Improvement].”<br />
It originally grew out of a British government sponsored effort to regularize IT Service Management (ITSM). <br />
==References==<br />
===Works Cited===<br />
Fong, E.N. and A.H. Goldfine. 1989. ''Information Management Directions: The Integration Challenge. '' National Institute of Standards and Technology (NIST) Special Publication 500-167, September 1989. https://csrc.nist.rip/library/NIST%20SP%20500-167.pdf <br />
<br />
Hammer, M., T.H. Davenport and J. Champy. 1986. ''Dispersion and Interconnection: Approaches to Distributed Systems Architecture'', Cambridge, MA: CSC Index Inc. and Hammer and Company, Inc. (June 1986). Available as: https://www.globalaea.org/general/custom.asp?page=Resources <br />
<br />
Hilliard, R. 2015. “Lessons from the fundamental unity of architecting”. ''Software Engineering in the Systems Context'', editors: Ivar Jacobson and Harold 'Bud' Lawson.<br />
<br />
Hofmeister, C. et al. 2007. “A general model of software architecture design derived from five industrial approaches”. ''The Journal of Systems and Software'' 80(1). <br />
<br />
ISO/IEC 25010:2011 ''Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models'', 4.2.3.2.<br />
<br />
ISO/IEC/IEEE 42010 Users Group. ''Survey of Architecture Frameworks'' Available as: http://www.iso-architecture.org/42010/afs/<br />
<br />
ISO/IEC/IEEE. 2011. ISO/IEC/IEEE 42010:2011, ''Systems and software engineering — Architecture description. ''<br />
<br />
PMI. 2013. ''Software Extension to PMBOK® Guide – Fifth Edition. '' Newtown Square, PA, USA: Project Management Institute (PMI). Available as: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/software-extension-5th-edition.<br />
<br />
Rivera, R. 2013. “The PRISM Architecture Framework – Was it the Very First Enterprise Architecture Framework?” ''Journal of Enterprise Architecture'', November 2013<br />
<br />
Zachman, J. 1987. “A Framework for Information Systems Architecture”. ''IBM Systems Journal'', pp454-470, 1987 <br />
<br />
===Primary References===<br />
IEEE Computer Society. ''Enterprise IT Body of Knowledge''. Available: http://eitbokwiki.org<br />
<br />
=-=Additional References===<br />
IT Capability Maturity Framework (IT-CMF): The Body of Knowledge Guide. 2015. Editors. Martin Curley, Jim Kenneally, Marian Carcary. Van Haren Publishing.<br />
<br />
Lessons from Systems Engineering Failures: Determining Why Systems Fail, The State of Systems Engineering Education, and Building an Evidence-Based Network to Help Systems Engineers Identify and Fix Problems on Complex Projects, Diane Constance Aloisio, December 2018.<br />
<br />
===International Standards Guiding EIT===<br />
ANSI/AIAA. 2012. ''ANSI/AIAA Guide to the Preparation of Operational Concept Documents. '' ANSI/AIAA G-043A-2012e.<br />
<br />
IEEE 2012 Std 828™-2012, ''IEEE Standard for Configuration Management in Systems and Software Engineering. ''<br />
<br />
ISO 10004:2012, Quality management—Customer satisfaction—Guidelines for monitoring and measuring<br />
<br />
ISO 10007:2003, Quality management systems—Guidelines for configuration management<br />
<br />
ISO 18238:2015, Space systems—Closed loop problem solving management<br />
<br />
ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models<br />
<br />
ISO/IEC 16350:2015, Information technology—Systems and software engineering—Application management<br />
<br />
ISO/IEC 19770-1:2012, Information technology—Software asset management—Part 1: Processes and tiered assessment of conformance<br />
<br />
ISO/IEC 20000-1:2011, (IEEE Std 20000-1:2013) Information technology—Service management—Part 1: Service management system requirements<br />
<br />
ISO/IEC 20000–2:2012, Information technology—Service management—Part 2: Guidance on the application of service management systems<br />
<br />
ISO/IEC TR 20000–10:2015, Information technology—Service management—Part 10: Concepts and terminology<br />
<br />
ISO/IEC TR 20000–11:2015, Information technology—Service management—Part 11: Guidance on the relationship between ISO/IEC 20000-1:2011 and related frameworks: ITIL®<br />
<br />
ISO/IEC TR 20000-12—Information technology—IT Service management—Part 12: Guidance on the relationship between ISO/IEC 20000-1:2011 and service management frameworks: CMMI-SVC®<br />
<br />
ISO/IEC/IEEE 14764-2006, Software Engineering—Software Lifecycle Processes—Maintenance<br />
<br />
ISO/IEC 15939:2007, Systems and software engineering—Measurement process<br />
<br />
ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description <br />
<br />
<br />
----<br />
<center>[[ Systems Engineering and Economics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Quality Attributes|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Enterprise_IT&diff=66926
Systems Engineering and Enterprise IT
2023-04-24T05:59:43Z
<p>Mhaas: Fixed block quotes</p>
<hr />
<div>----<br />
'''''Lead Authors:''''' Chuck Walrad and Richard Hilliard<br />
----<br />
This article forms part of the [[Related Disciplines]] knowledge area (KA). It discusses enterprise IT, building upon the concepts and practices of Systems Engineering presented elsewhere in the SEBOK. Systems Engineering is integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of ''engineered technical systems''. <br />
<br />
== Enterprise IT Introduction==<br />
Although it had its origin in the need to improve success rates in U.S. Government outsourcing of technical systems, Systems Engineering is also integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of [https://www.incose.org/about-systems-engineering/system-and-se-definition/systems-engineering-definition#ENGINEERED_SYSTEM engineered technical systems].<br />
Examples of EIT systems include enterprise resource planning, supply chain management and customer relationship management systems, accounting, finance, inventory and order management, marketing, planning, purchasing, and sales.<br />
In the late 1980s and throughout the 1990s, EIT organizations became increasingly aware that the success rates of IT projects were very low, and that their enterprise customers were increasingly unhappy with their EIT investments. The Standish Group sought to understand what was going on. Their findings were presented in the [https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf Chaos Report] (1994):<br />
The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable but could easily be in the trillions of dollars.<br />
As a result, commercial IT organizations, through the auspicious parallel emergence of the Total Quality Management movement and the increasingly widespread development of application development methodologies (ADM) by IT management consulting firms, recognized the need for the principles of Systems Engineering and cross-functional teams (Integrated Product Teams [https://www.sebokwiki.org/wiki/Integrated_Product_Team_(IPT)_(glossary)]. It should be noted that there is considerable overlap today between what constitutes Systems Engineering and what constitutes [[Project and Portfolio Management|Relationships between Systems Engineering and Project Management]] (see [https://www.pmi.org/learning/library/bridging-gap-program-management-systems-engineering-6213 PMI]). This article does not attempt to resolve this issue. Note that the “[[Related Business Activities|following business management activities]] can be ''supported'' by enterprise systems engineering (ESE) activities” [emphasis added]: <br />
* mission and strategic planning,<br />
* business processes and information Management,<br />
* performance management,<br />
* portfolio management,<br />
* resource allocation and budgeting, and<br />
* program and project management.<br />
Note that these same areas have been designated as being supported by Project Management Offices. However, since a key difference between project management and systems engineering has been identified as the requirement that the latter includes technical expertise in the product/system of concern, focus should be on systems engineering and integrated product teams (IPTs). <br />
With IPTs, each product is shepherded from concept through delivery and support to retirement by a cross-functional team that includes representatives from each area of responsibility, such as customer requirements development, design and development, test, configuration management, release engineering, delivery, and support.<br />
As enterprises have come to depend more and more on technology to perform effectively, Enterprise IT organizations have matured, often due to the influence of IT consulting firms that make it their business to keep abreast of best practices.<br />
<br />
== EIT Concepts ==<br />
This knowledge area (KA) discusses enterprise IT, building upon the concepts elucidated in the IEEE/ACM ''[http://eitbokwiki.org EITBOK Guide to the Enterprise Information Technology Body of Knowledge]'' and general concepts of Systems Engineering elsewhere in SEBOK. <br />
An enterprise may be viewed from various perspectives: such as a system or a [[system of systems (SoS)|Enterprise Systems Engineering]]:<br />
* system-like enterprise: enterprises, like other systems, may have a tight coupling, single-executive function; <br />
* system of systems-like enterprise: may be a loosely coupled group of organizations with blurred boundaries and (yet) with (some) shared outcomes.<br />
The choice of perspective may vary with many factors: the enterprise itself, the mission or purpose, or the particular engineering task at hand. We can view an enterprise as a system with inputs and outputs in relation to the outside world, or a system of systems interacting through their individual inputs and outputs. <br />
An enterprise usually involves one (or more) organization(s) but need not be identified with the organization. As the scope of human and organizational participants of the enterprise widen, there may be no single point of control. For example, an ''extended enterprise'' could include a company, its suppliers and customers.<br />
Whatever perspective (system-like, SoS-like, other) is taken there are [[key ingredients|Enterprise Systems Engineering Background]] of any enterprise: capabilities, individual (competencies) and the organizational design. [[Capabilities|Enterprise Capability Management]] can be further categorized: “There are three different kinds of capability: organizational capability, system capability, and operational capability.” These capabilities determine what the enterprise is able to produce which may be external offerings or internal mechanisms. Operational capabilities create services and/or products which in turn produce value as determined by stakeholders. The capabilities of an enterprise are realized through [[Enterprise Systems Engineering Background|various enterprise elements]], including: “hardware, software, personnel, facilities, data, materials, techniques, and even services”. which include “soft” items, like people, processes, principles, policies, practices, organizations, doctrine, theories, and beliefs.<br />
EIT capabilities exist through lifecycles spanning from creation through eventual replacement and disposal. ''Life cycle models'' are schemes to aid in the understanding, design, planning and management of the capability of interest. <br />
“A life cycle for a system generally consists of a series of stages regulated by a set of management decisions which confirm that the system is mature enough to leave one stage and enter another.” Basic life cycle terms and concepts are discussed in [[System Lifecycle Approaches]]. Some typical life cycles are discussed in [[System Lifecycle Models]].<br />
A life cycle-based approach can be deployed across the several levels and used to manage evolution. These levels are:<br />
* the enterprise itself,<br />
* the processes and organizations constituting the enterprise,<br />
* the systems enabling the capabilities, services or products provided. <br />
It is important to distinguish between ''product'' and ''project'' lifecycle models. A product’s life cycle extends from its initial concept approval, through development and distribution, to its retirement. This is the cycle that is managed within an Enterprise IT organization, since EIT must manage the hardware or software product from its introduction, in the case of acquired capabilities, or from its concept approval and development, in the case of capabilities it builds, through its deployment, maintenance and eventual retirement (withdrawal). Each of these stages is usually managed as a project or a series of projects.<br />
However, most discussions of life cycles within software and systems discussions focus on ''project'' life cycles. See, for example, the ''Software Extension to PMBOK Guide'' (PMI 2013).<br />
==System of Systems Context in EIT==<br />
“Enterprise IT” (EIT) is used both to refer to the technology organization/business unit within the enterprise and to the enterprise’s information technology systems. In this article, we use EIT to refer to the technology systems. When referring to the organization, we use the phrase “Enterprise IT organization” or EIT organization. <br />
Enterprise IT organizations are responsible for complex socio-technical systems. Socio-technical systems in a business context (thus, EIT) contain technical elements (software, hardware, networks, storage, databases, etc.) but they also contain essential human components and necessary business processes. As covered in [[Introduction to Systems Engineering Fundamentals]], they exist in an engineered System Context that is a set of system component interrelationships within a real-world environment:<br />
This includes where problems come from and how they are defined, how we identify and select candidate solutions, how to balance technology and human elements in the wider solution context, how to manage the complex organizational systems needed to develop new solutions, and how developed solutions are used, sustained and disposed of. … Systems Engineering should consider the full Engineered System Context so that the necessary understanding can be reached and the right systems engineering decisions can be made. <br />
Socio-technical systems also have the following key characteristics: ''Openness'' in that they strongly interact with their environments, and ''unfinished'' in that they evolve over time.<br />
A complex of EIT systems is essential to the successful functioning of the humans in the enterprise. They rely on EIT’s technology for communication, for paying employees, for people management, for business measurement, and often for managing supply chains. Thus, “EIT needs to be viewed as a strategic partner to all the other functions and business units within an enterprise. This means that the results produced by EIT along with its effectiveness and efficiency are all critically important to the success of the enterprise.” [http://eitbokwiki.org/What_is_the_Enterprise_Perspective%3F]<br />
To accomplish this mission, the EIT organization builds and acquires new systems or system components, integrates them into the mega System of Systems, and maintains the integrity and interoperability of the individual components, but also the integrity of the entire complex of systems. In addition, security and performance levels must be achieved, benchmarked and maintained or improved.<br />
==Major concerns of the EIT Organization==<br />
The [http://eitbokwiki.org ''Enterprise IT Body of Knowledge''] provides a good deal of information about these major concerns, which we will not replicate here. Rather, links to the relevant areas are provided. The EITBOK demonstrates how, in providing technology systems and services to the enterprise, the EIT organization must skillfully manage such concerns as the following.<br />
<br />
===Enterprise Architecture===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Enterprise_Architecture Enterprise Architecture] for additional information. ''<br />
[http://eitbokwiki.org/Glossary#ea ''Enterprise architecture''] (EA) is the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. EA applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their organization's strategies. Enterprise architecture builds upon many of the concepts and practices of [[System Architecture Definition|systems architecture]] and also software architecture [https://www.sebokwiki.org/wiki/System_Architecture_Definition].<br />
This section will discuss Enterprise Architecture from the perspective of key [[Principles of Systems Thinking]], designated in this article with '''''bold italics'''''. There are many commonalities in architecture whether one is architecture systems, software or the enterprise [Unity]. In this article we highlight both commonalities and differences between Enterprise Architecture and Systems Architecture. <br />
Architecture takes place at the juncture of design problems and their solutions. Design problems rarely arrive fully formulated or “hatched” for the architect; much of the architecture effort is to analyze or formulate the problems to be solved. Often this involves negotiation both within the enterprise and with outside stakeholders. Possible solutions are limited by resources and schedule and therefore often must also be negotiated.<br />
A dominant principle of Enterprise Architecture is '''''separation of concerns''''' (SoC). This is due to the complexity of enterprises, with many forces acting upon them; the many technologies and disciplines involved in their creation and day-to-day operations; and due to the diversity of stakeholders involved in the enterprise (see [[EIT Roles]]). <br />
An application of SoC is the '''''boundary''''' principle which is crucial to separate what is “inside” the enterprise from what is “outside”. While the former is often under the enterprise’s control, the latter is often beyond its control. <br />
For some systems, determining the boundary is a key decision, subject to many possibilities and consequences. This is perhaps less the case for enterprises whose bounds are determined by the extent of organizations, regulations, supply chains or other criteria. Within an established boundary, the '''''holism''''' principle applies: to treat the enterprise as a unified whole, and, in particular, with respect to the '''''interaction''''' of the enterprise with its ''environment''—including stakeholders, other enterprises and systems. From an enterprise IT perspective, an enterprise is a ''system of systems. '' SoC offers a way to focus on the constituent systems in terms of their interconnections to one another to form the enterprise.<br />
Another useful application of SoC is to apply the principle of '''''multiple views''''' to depict the architecture of the enterprise in different ways to address the diverse interests (i.e., ''concerns'') of an enterprise’s various stakeholders. Each ''architecture view'' presents a specific perspective on the enterprise. To be understandable to its audiences (those various stakeholders), each view should follow the conventions of its ''architecture viewpoint'' (ISO/IEC/IEEE 42010 2011). Just as a map should have a legend, each view should have a documented viewpoint providing a prescribed set of conventions for looking at the enterprise through the resulting view. A viewpoint definition serves as a contract between the architect and stakeholders on ''how'' a selected set of concerns are to be addressed. Each viewpoint allows the architect to consider the enterprise in terms of various kinds of elements and relations among them and to present that view to those “concerned” stakeholders. Dominating concerns in enterprise architecture include interoperability, quality of systems and services, operations, managing change, and alignment with the enterprise’s mission, market, and technology. Via the principle of '''''dualism''''', we recognize that some viewpoints are paired, such as with process/data duality. Another pervasive duality in the enterprise is of people/technology in terms of what capabilities are automated and which are performed by people.<br />
In support of enterprise architecture, there are numerous ''enterprise architecture frameworks'' each providing a pre-defined, integrated set of viewpoints to frame typical, recurring concerns (ISO/IEC/IEEE 42010 Users Group 2022). The earliest recorded framework was (Hammer et al. 1986), developed in the mid-1980s in response to growing availability of distributed computing to the enterprise (Rivera 2013). In the late 1980s, US NIST created its Enterprise Architecture Model as a guide for US federal departments to organize their IT offerings (Fong and Goldfine 1989). NIST’s 5-layer model remains influential today. Despite never using the term “enterprise,” Zachman’s information systems architecture has had a major influence on how subsequent frameworks have been organized and depicted using grids or cubes. Later frameworks have evolved in response to emerging concepts, such as the move from client-server to service-oriented applications, as in the OASIS SOA Reference Model and its associated framework. The 1990s saw a proliferation of frameworks for defense enterprises including US DODAF, UK MODAF, NATO’s NAF and led to successors such as OMG’s UAF.<br />
Yet another application of '''''separation of concerns''''' is distinguishing today’s needs versus facilitating future needs; balancing '''''stability/change''''' and highlighting the temporal planning aspect of architecture of the enterprise. In concert with applying SOC, the architect uses the principle of '''''abstraction''''' to “forget” some details of the subject and thus focus on essentials. Just as SoC is a way of taking things apart, '''''abstraction''''' is a way of unifying or putting like things together through generalization. These two principles are perhaps the most central to architecture. SoC and abstraction work together: SoC picks out subjects and abstraction helps architects to focus upon the essentials of each subject. <br />
Returning to the '''''boundary''''' and '''''holism''''' principles, the enterprise architect applies these recursively. As architecting proceeds, the internal details of the enterprise become known in terms of '''''interaction''''' among its parts and other '''''relations'''''. Again, '''''multiple views''''' are used to factor specific '''''relations'''''into distinct views. Typical relations include Causality, Dependency, Client-Server, and Input-Output. <br />
There are a variety of ways to structure the enterprise based upon stakeholder needs, mission or charter, technologies or capabilities already in place. Among these are structuring principles including: <br />
* '''''Modularity''''' (separate and group capabilities into modules by commonalities); <br />
* '''''Network''''' (modules are linked together); <br />
* '''''Encapsulation''''' (separating architecture modules use from how they are implemented); <br />
* '''''Layer Hierarchy''''' (separation through gradual refinement); <br />
* ''''' Regularity''''' (uniformity of interactions, of structure within layer, within network). <br />
* ''''' Similarity/Difference''''' (recognizing the limits of Regularity)<br />
A simple pattern for architecture has been defined (Hofmeister ''et al. '' 2007). Its elements are Analysis, Synthesis and Evaluation. See Figure 1 below. <br />
''Architecture Analysis'' formulates architecturally-significant requirements (ASRs)—those requirements which influence an enterprise’s architecture. Architecture analysis is based on identified concerns and other information based on understanding the enterprise’s environment, known requirements, stakeholder needs and any constraints. ASRs reflect the “design problems” that the architecture must solve. In many cases, negotiations take place to modify incoming needs, requirements and expectations to make solutions possible. The result of this activity takes the form of ASRs, including architecture principles and initial enterprise-wide decisions.<br />
''Architecture Synthesis'' develops candidate solutions in response to the concerns and ASRs. During Synthesis the architect works out the details of solutions to the identified design problems, tradeoff and interactions between them which are likely to generate further design problems. Synthesis elaborates the ASRs, principles and initial decisions into more detailed solution elements. The principle of ''''' EQUIFINALITY''''' reminds us that for many stable situations (i.e., states of the enterprise), there are many ways to reach those states.<br />
''Architecture Evaluation'' validates whether chosen solutions satisfy ASRs or whether rework is needed (ISO/IEC/IEEE 42030 2019).<br />
Applying the principles discussed above is pervasive in enacting the Analysis–Synthesis–Evaluation pattern iteratively. <br />
<br />
<br />
Figure 1 A pattern for Architecture<br />
While there are many commonalities among EIT, systems and software architectures, Figure 2 addresses the relationships ''between'' them. Viewing an enterprise as a system, the EIT architecture governs the fundamental IT decisions of the enterprise. That enterprise might be extended to “outsiders” such as vendors, suppliers and perhaps customers. Depending upon the enterprise, the ''governs'' relationship may entail very strict rules or loose guidance. <br />
Within the enterprise, the ecosystem of systems, applications and data may be viewed as a system of systems. The EIT Architecture constrains the architectures governing individual systems, applications and data stores within the enterprise, so that these are able to interoperate and otherwise “play nicely” together.<br />
<br />
Figure 2 Relating Enterprise IT, Systems and Software Architecture<br />
===Strategy and Governance===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance] for additional information. ''<br />
<blockquote><br />
[http://eitbokwiki.org/Glossary#eit Enterprise information technology] (EIT) governance is the established process of defining the strategy for the EIT organization and overseeing its execution to achieve enterprise goals. Strategic planning translates the larger enterprise’s goals into EIT goals and defines what EIT must do to achieve those goals. This effort then communicates this hierarchy of goals: EIT goals as well as how they support the enterprise’s goals. EIT governance drives needed changes to achieve those goals, while maintaining agreed levels of operation. Taking into account various perspectives (such as financial, historical, environmental, and future projections), a strategic plan is a roadmap for action and change, both vertically and horizontally, across the EIT organization. The EIT organization’s strategic plans are based on the enterprise’s strategic plans, focusing on EIT’s role in them; EIT governance provides a monitoring and control framework to achieve strategic goals and objectives. Thus, EIT governance is essential for achieving the EIT strategy and goals..<br />
-[http://eitbokwiki.org/Strategy_and_Governance EITBOK wiki]<br />
</blockquote><br />
<br />
The principle of ''''' PARSIMONY''''' applies here, too (see [[Principles of Systems Thinking]]). These principles will be designated in this article with '''''bold italics'''''. For example, the simplest possible measurement and reporting systems are most likely to be used and not corrupted. Similarly, the EIT organizational structure should be straightforward and easy to traverse so that staff can communicate and problem-solve in teams.<br />
In governing the EIT organization to meet its dual goals of satisfying its customers and meeting its budget and schedule commitments, EIT management encounters the difficulty of managing in the face of '''''dualism''''', “ensuring a constant dynamic balance often through a cyclic dominance of one element and then the other”. The most obvious instance of handling ''''' dualism''''' in EIT is the trade-off between budget, project prioritization and features within projects.<br />
===Change===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Change_Initiatives Change Initiatives] for more information. ''<br />
There are two levels of change management discussed in the EITBOK: organizational change management and changes to the IT organization’s assets, whether they be software, hardware, or telecommunications systems.<br />
In the larger sense, the introduction of new systems and services often also requires changes in people’s jobs and in the processes used to accomplish those jobs. Such efforts are intended to increase business value. Such changes require change initiatives because they involve guiding a mixture of stakeholders through the change process. This is one aspect of [http://eitbokwiki.org/Change_Initiatives change management].<br />
Change also occurs when existing systems or services must be updated to meet new needs. Depending on the scope of the proposed changes, a change initiative may be required in this situation, too. At any rate, a change request process must be initiated and tracked to disposition (deferral, rejection, or implementation). Changes also come about as a result of defect reports. In such cases, the defect report must be tracked throughout the report’s life cycle, to disposition (deferral, rejection, or implementation).<br />
These latter types of change management are discussed in detail in the EITBOK’s section on [http://eitbokwiki.org/Operations_and_Support Operations and Support].<br />
===Interoperability of Component Systems===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Interoperability interoperability] for more information. ''<br />
As explained in the [http://eitbokwiki.org/Interoperability#One EITBOK], ''interoperability'' means “the ability of systems (including organizations) to exchange and use exchanged information without knowledge of the characteristics or inner workings of the collaborating systems (or organizations).” This definition is based on an ISO definition: “degree to which two or more systems, products, or components can exchange information and use the information that has been exchanged.” (ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models, 4.2.3.2. ) Note that this definition includes hardware components as well as software systems and the organizations in which they are used.<br />
Because technology changes so rapidly, and organizations themselves are frequently changing, achieving and maintaining interoperability is crucial. It is one of the main reasons that providing IT services is difficult and how it differs from engineering and delivering finished products, whether off-the-shelf products or bespoke systems.<br />
===Security of Systems and Data===<br />
<blockquote><br />
There are only two types of companies: those that have been hacked, and those that will be.<br />
-FBI Director Robert Mueller, October 2012<br />
</blockquote><br />
<br />
<blockquote><br />
There are two kinds of big companies in the United States. There are those who've been hacked by the Chinese and those who don't know that they've been hacked by the Chinese<br />
-FBI Director James Comey, October 2014<br />
</blockquote><br />
''See the EITBOK’s section on [http://eitbokwiki.org/Security security] for additional information. ''<br />
While there are many definitions for security, most include the three dimensions of confidentiality, integrity, and availability (sometimes referred to as the [http://eitbokwiki.org/Glossary#ciatriad CIA triad]). As such, the primary goal of EIT security is to preserve the confidentiality, integrity, and availability of information and information systems. <br />
The principles behind an organization’s [http://eitbokwiki.org/Glossary#isms information security management system] (ISMS) should be to design, implement, and maintain a coherent set of policies, processes, and systems that keep the risks associated with its information assets at a tolerable level, and yet, manage the cost and inconvenience of said risk management. As such, the goals of EIT security are to:<br />
* Always understand the current risk tolerance of the enterprise with respect to information and device security.<br />
* Understand the security threats and potential damages to information, devices, and individuals.<br />
* Create and follow policies and procedures that keep cyberattack risk and damages at or below a tolerable level.<br />
* Effectively and efficiently detect and deal with<br />
[http://eitbokwiki.org/Security#One cyberattack incidents].<br />
Ensuring security in EIT has been made even more pressing and more difficult by the proliferation of mobile devices in enterprises and their ever-increasing use to conduct business. Increasingly, personal devices (Bring Your Own Device – BYOD) are used, accessing both corporate networks and public networks. The cost of [https://www.checkpoint.com/downloads/products/check-point-mobile-security-survey-report2013.pdf mobile security incidents] very easily can outweigh the cost of the mobile device itself. <br />
==Quality of Systems and Services==<br />
The Enterprise ''Information'' Technology organization has, since its origins, had as its primary responsibility the timely provision of information to the larger organization. The information is expected to be not only timely, but also accurate and relevant. While the EIT organization itself may not be responsible for creating the data, it is responsible for the physical and logical validity and [https://simplicable.com/new/data-integrity-vs-data-quality integrity of the data] that is used to construct information. It is for this reason that defining and using appropriate processes is essential to ensure high-quality operation, including the development or acquisition, implementation and integration of new or changed capabilities.<br />
The EITBoK details the quality concepts of<br />
* How to approach measuring [http://eitbokwiki.org/Quality#Measuring_Quality Quality]<br />
* The importance of Quality in [http://eitbokwiki.org/Quality#Requirements_Management Requirements Management]<br />
* Understanding an organization’s [http://eitbokwiki.org/Quality#Quality_Capability Quality Capability]<br />
* The differences between [http://eitbokwiki.org/Quality#QMS_and_QC_vs._QA QMS, QC and QA]<br />
* Cost of Quality in [http://eitbokwiki.org/Quality#Technical_Debt_and_the_Cost_of_Rework Technical Debt and the Cost of Rework]<br />
==Disaster Preparedness==<br />
<br />
As explained in the [http://eitbokwiki.org/Disaster_Preparedness EITBOK], disaster preparedness and [http://eitbokwiki.org/Glossary#dr disaster recovery] (DR) support business-continuity planning and include planning for EIT resiliency, as well as recovery from adversity, so that critical business services affected are restored to a satisfactory working state within an [http://eitbokwiki.org/Glossary#acceptable acceptable] timeframe after an event.<br />
The EITBoK devotes a chapter to how the EIT organization and its parent must plan in advance for how it will provide sufficient organizational resilience to recover from disasters and return to normal operation as rapidly as possible.<br />
It provides the following examples of disasters and service interruptions that could occur and should be considered in prevention and recovery planning:<br />
These are examples of disasters:<br />
* Natural disaster affecting datacenters or EIT service operations (flood, fire, earthquake, wind)<br />
* Security breach resulting in a disaster (destruction of data, admin password changes, virus/malware installation, sabotage)<br />
* Usage error (accidental deletion, unplug/turn off system resulting in corruption)<br />
* Utility failure affecting datacenters (loss of power even after UPS)<br />
* Vendor failure (cloud provider security failure, oil spill)<br />
* Staffing issue (employment dispute/walkout, epidemic)<br />
These are examples of unpreparedness:<br />
* Requiring use of computers or printers when power is out<br />
* Requiring use of Internet when power or connectivity is out<br />
* Single point of knowledge/control for administration access<br />
* Lack of offsite backup storage<br />
* Lack of working restoration from backups<br />
* Lack of failover datacenters in separate locations<br />
* Undocumented or out-of-date documentation for system interfaces<br />
*Requiring use of phones that are out of power<br />
* Lack of designation of leaders in restoration efforts (who is in charge of restoring service and they know they are in charge)<br />
* In general, no cohesive, comprehensive EIT service restoration plan<br />
==Operations and Support of Delivered Systems and Services==<br />
[http://eitbokwiki.org/Operations_and_Support Operations and support activities] focus on maintaining an operation normal state in EIT environments, meaning that systems and processes execute according to expectations, with no surprises to users. This desired normal state requires the careful management of EIT assets and services via Operations, as well as of users via Support.<br />
Normal states can be disrupted either by the expected and planned transition of an asset, or by an unexpected event, be it as large as a disaster or by the discovery of a system defect. In the former case, the Disaster Recovery Plan is executed; in the latter, incident management kicks in when a system halts, or problem management is exercised when an operational system is not functioning as expected. The processes needed to ensure effective application of these complex functions is detailed in the [http://eitbokwiki.org/Operations_and_Support#Guiding_Principles Operations and Support Knowledge Area] within the EITBOK. <br />
ISO/IEC/IEEE 20000 may be used by any organization to develop and manage EIT operations, along with the current version of [https://www.servicenow.com ITIL].<br />
ITIL for many is the tool of choice for the operations and infrastructure side of IT, particularly for IT services. <br />
==Ethics==<br />
See the EITBOK’s section on [http://eitbokwiki.org/Ethics ethics] for additional information.<br />
Both the IEEE and ACM require their members to adhere to Codes of Ethics. See the [https://www.ieee.org/about/corporate/governance/p7-8.html IEEE Code of Ethics] and [https://www.acm.org/code-of-ethics ACM Code of Ethics and Professional Conduct]. Both of these can be downloaded freely. In addition, the IEEE Computer Society and the ACM worked together on the [https://dl.acm.org/action/downloadSupplement?doi=10.1145%2F265684.265699&file=acm-se-code-of-ethics.html Software Engineering Code of Ethics] (also available [https://dl.acm.org/doi/10.1145/265684.265699 here]).<br />
The organization should create an easily accessible Code of Ethics:<br />
* Ethical assertions should be documented and socialized in EIT in the form of a Code of Ethics, tied to the overall business code of ethics, and signed off by all staff so that violations can be cause for reprimand or dismissal.<br />
* Vendors should be held to similar ethical standards.<br />
* Lists of employees who have signed off on the Code of Ethics are maintained by EIT governance.<br />
The EITBOK has identified EIT ethical topics that include:<br />
* Those actions and decisions that may be illegal<br />
* Consideration of the social impact of the work at hand—if it will cause harm<br />
* Alignment of business and EIT strategies and policies to an ethical standard<br />
* Incorporation of the ideals of professionalism<br />
* Adherence to applicable regulatory intent<br />
* Protection for whistle blowers<br />
Areas to specifically highlight:<br />
* Activities that interfere with or corrupt the proper function of computers, applications and systems<br />
* Activities that interfere with digital privacy or intellectual rights of others<br />
* Respect for confidentiality, privacy, permissions, and access rights<br />
* Inappropriate bias (skewing) of analysis and reporting<br />
* Inaction in the face of likely ethics violations<br />
==EIT Roles==<br />
Several roles play a part in accomplishing the EIT organization’s mission. Just as a systems engineer can play several roles in a given project, so might several people in an EIT project combine to fulfill the systems engineering function. <br />
The function of EIT systems engineering is to orchestrate systems development, delivery and operation such that the larger organization achieves favorable outcomes in complex environments. Unlike systems projects that are built for known problems, EIT systems may change in unpredictable ways. A primary concern focuses on how quickly systems adapt to change. This entails a type of resiliency based on skills in establishing options and alternative solutions as well as strategies tailored to the volatility of changing needs and available technologies. It also requires expertise in assuring that systems quality is assured from the start.<br />
Different countries, geographic areas and organizations do not always use the same terminology to reference the functions that the roles contributing to systems engineering perform. The following section will provide information about some major international models for defining EIT skills and capabilities. Generally, though, the necessary roles across the product life cycle include these:<br />
* Business Sponsor/Champion<br />
* Enterprise Architect<br />
* Systems Engineer<br />
* Financial Manager<br />
* Application Architect<br />
* Business Analyst and/or Process Analyst<br />
* Data Analyst and/or Data Architect<br />
* Software Engineer and/or Programmer<br />
* Quality Assurance & Testing<br />
* Network Engineer<br />
* Telecoms Engineer<br />
* Integration Expert <br />
* Transition to Operations Manager<br />
* Release Manager<br />
* Availability Manager<br />
* Capacity Manager<br />
* Change Manager<br />
* Configuration Manager<br />
* EIT Operations Manager<br />
* Incident Management<br />
* Problem Manager<br />
* Service Level Manager<br />
* Database Administrator<br />
* Network Manager<br />
* Product Manager<br />
System engineering activities orchestrate the work of these roles so that they function together, rather than in silos or at cross purposes.<br />
==Examples of Systems Engineering in EIT==<br />
Systems Engineering provides a holistic discipline for integrating and managing the contributions of all roles needed to establish and provide EIT products and services. It ensures that a single perspective does not dominate outcomes; instead, it seeks balance among the many disciplines represented above in creating a consistent product or service that meets the interests and needs of enterprise users (and, perhaps, partners). It boils down to common sense, technical sense, knowing when to ask the right questions, and getting the data to support the answers to those questions. System Engineering achieves this via Systems Engineers. In many instances, though, the SE function is accomplished through Project Management approaches using Integrated Product Teams that include technical experts. Thus, although not specifically calling out a Systems Engineering function, the use of IPTs involved the use of SE practices.<br />
A doctoral dissertation from Purdue University performed a survey and causal analysis of project failures and of accidents(Aloisio, 2018). The results were similar to those found in reviews of IBM consulting projects in the 1990s . The following are examples of Systems Engineering interventions that prevented project failures. Almost all point to the lack of the System Engineering balancing act needed for product delivery.<br />
* A widely used document processing product was undergoing a major upgrade. The new VP of Engineering wanted a project review before committing to a schedule. The review showed that the proposed schedule only considered the development effort and did not give sufficient weight to the voices of the testing and documentation organizations, while the needs of the tech support group had been completely overlooked. By establishing an integrated product management team that included technical expertise, as well as expertise in work breakdown and estimating, a realistic effort was defined and the resulting 9-month schedule was met within 3 weeks.<br />
* A Silicon Valley start-up was depending entirely on an offshore development effort to produce its first product. All senior management was in the U.S. The VP of engineering made monthly visits to the development team. The CEO began to feel uneasy about the team’s ability to deliver on schedule sensing that a lot of finger pointing within the development team itself signaled problems. There was no SE or IPT guiding the project. The VP of Engineering seemed unable to sort things out. A project review showed that the probable delivery date was at least 6 months beyond what the CEO was being told. The project was shut down.<br />
* A major player in Human Resource Management had made commitments to deliver a new product. The project involved more than 100 people across the U.S. The delivery date kept slipping. Project roll-out would involve both installation of software and hardware at client sites, as well as installation and staff training at the large, centrally located Client Services organization. Executive Management needed to decide whether to reorganize this very expensive effort or cancel it. Again, the successful solution depended on establishing an effective cross-functional team (IPT) that necessarily included representatives from the technical teams. The IPT was supported by a newly established Project Management Office (PMO). The PMO integrated the geographically disparate efforts by establishing communication channels, as well as common estimating and scheduling practices. The PMO also instituted monthly critical metrics reports to show the IPT bottlenecks and inefficiencies across the project, from development efforts to Client Services set-up to Payroll technical support.<br />
There are far more examples of the lack of systems engineering practices in EIT projects than in their successful use (unfortunately, this seems also to be true in lots of software projects outside of EIT). Systems Engineering provides a holistic discipline for integrating and managing the contributions of all of the roles needed to provide EIT products and services. It ensures that a single perspective does not dominate outcomes.<br />
==Key External Models of EIT Organizational Capability and Maturity==<br />
Because EIT is critical to businesses globally, considerable effort has gone into establishing universal frameworks for EIT skills, along with definitions of levels of capability of each skill. In addition, at least 2 models have been developed for evaluating the organizational performance of EIT. The effectiveness of systems engineering is key to the effectiveness of the EIT organization.<br />
===IT-CMF: IT-Capability Maturity Framework=== <br />
The IT-CMF had its origin in a quality improvement effort at Intel Labs Europe in Ireland. Its intent, as described at the <br />
[https://cio-wiki.org/wiki/IT_Capability_Maturity_Framework_(IT-CMF) CIO Index website] was to quantify and demonstrate the true value impact of IT. IT-CMF is used to measure, develop, and monitor an organization’s EIT capability maturity. It consists of 35 EIT management capabilities organized into four macro capabilities: managing EIT like a business; managing the EIT budget; managing the EIT capability; and managing EIT for business value. Its 35 critical capabilities (CCs) are [http://eitbokwiki.org/Enterprise_IT_Maturity_Assessment described] as “A defined EIT management domain that helps mobilize and deploy EIT-based resources to effect a desired end, often in combination with other resources and capabilities”. <br />
===CMMI: Capability Maturity Model Integration (US)===<br />
The CMMI had its origin in 1987 in a model requested by the U.S. Department of Defense for determining the capability maturity of contractor software development organizations. This became the Capability Maturity Model (CMM). Since then, it has been expanded into a set of Capability Maturity Models, all based on five levels of demonstrably increasing maturity as measured by organization performance. That set was then integrated and became the CMMI. The CMMI set addresses [https://cmmiinstitute.com/dev Development], [https://cmmiinstitute.com/svc Services], [https://cmmiinstitute.com/sm Supplier Management], [https://cmmiinstitute.com/pm People Management], and [https://cmmiinstitute.com/dm Data Management].<br />
===SFIA: Skills Framework for the information Age (Europe, Canada and US)===<br />
The SFIA Framework has been downloaded and used by organizations and individuals in nearly 180 countries. It can be downloaded for free at [https://www.sfia-online.org]. It identifies 97 professional skills across EIT and supporting areas with seven levels of responsibility, which provide generic levels of responsibility, taking into account reflect experience and competency. These describe the behaviors, values, knowledge, and characteristics that an individual should have in order to be considered competent at a particular level.<br />
===E-CF: European Competency Framework (EU)===<br />
The ECF was the first sector-specific implementation of the European Qualifications Framework (EQF). The European Norm (EN) 16234-1 European e-Competence Framework (e-CF) provides a reference of 41 competences as applied at the Information and Communication Technology (ICT) workplace, using a common European reference for competences, skills, knowledge and proficiency levels. The E-CF Explorer web tool is available [https://ecfexplorer.itprofessionalism.org/ online].<br />
===I Competency Dictionary: EIT skills as Defined by METI/ IPA (Japan)===<br />
The Japanese government’s Information-Technology Promotion Agency (IPA), established by the Ministry of Economy, Trade and Industry (METI) developed the ”I Competency Dictionary” (iCD) to support the IT Engineers Examination. It underlies the METI/IPA Skills Standards for IT Professionals, abbreviated as ITSS, established in 2002. ITSS organizes skills within the information services industry into 11 job categories and 35 specialty fields. In each field, there are seven levels of competence based on individual experience and ability to perform. One appealing feature of ITSS is that this standard allows engineers to draw roadmaps for their own futures and career advancement (Career Path). Approximately 90% of large enterprises and over 60% of SMEs in Japan have introduced or are considering using ITSS. Information in English is available at https://www.ipa.go.jp/english/humandev/forth.html.<br />
===ITIL: Information Technology Infrastructure Library===<br />
According to ITLIlibrary.org, the ITIL Open Guide website, “The Information Technology Infrastructure Library (ITIL) defines the organisational structure and skill requirements of an information technology organisation and a set of standard operational management procedures and practices to allow the organisation to manage an IT operation and associated infrastructure. … The [https://www.itlibrary.org/ “library”] itself continues to evolve. This comprises five distinct areas: <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Strategy ITIL Service Strategy]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Design ITIL Service Design]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Transition ITIL Service Transition]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Operation ITIL Service Operation]; and <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Continual_Service_Improvement ITIL Continual Service Improvement].”<br />
It originally grew out of a British government sponsored effort to regularize IT Service Management (ITSM). <br />
==References==<br />
===Works Cited===<br />
Fong, E.N. and A.H. Goldfine. 1989. ''Information Management Directions: The Integration Challenge. '' National Institute of Standards and Technology (NIST) Special Publication 500-167, September 1989. https://csrc.nist.rip/library/NIST%20SP%20500-167.pdf <br />
<br />
Hammer, M., T.H. Davenport and J. Champy. 1986. ''Dispersion and Interconnection: Approaches to Distributed Systems Architecture'', Cambridge, MA: CSC Index Inc. and Hammer and Company, Inc. (June 1986). Available as: https://www.globalaea.org/general/custom.asp?page=Resources <br />
<br />
Hilliard, R. 2015. “Lessons from the fundamental unity of architecting”. ''Software Engineering in the Systems Context'', editors: Ivar Jacobson and Harold 'Bud' Lawson.<br />
<br />
Hofmeister, C. et al. 2007. “A general model of software architecture design derived from five industrial approaches”. ''The Journal of Systems and Software'' 80(1). <br />
<br />
ISO/IEC 25010:2011 ''Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models'', 4.2.3.2.<br />
<br />
ISO/IEC/IEEE 42010 Users Group. ''Survey of Architecture Frameworks'' Available as: http://www.iso-architecture.org/42010/afs/<br />
<br />
ISO/IEC/IEEE. 2011. ISO/IEC/IEEE 42010:2011, ''Systems and software engineering — Architecture description. ''<br />
<br />
PMI. 2013. ''Software Extension to PMBOK® Guide – Fifth Edition. '' Newtown Square, PA, USA: Project Management Institute (PMI). Available as: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/software-extension-5th-edition.<br />
<br />
Rivera, R. 2013. “The PRISM Architecture Framework – Was it the Very First Enterprise Architecture Framework?” ''Journal of Enterprise Architecture'', November 2013<br />
<br />
Zachman, J. 1987. “A Framework for Information Systems Architecture”. ''IBM Systems Journal'', pp454-470, 1987 <br />
<br />
===Primary References===<br />
IEEE Computer Society. ''Enterprise IT Body of Knowledge''. Available: http://eitbokwiki.org<br />
<br />
=-=Additional References===<br />
IT Capability Maturity Framework (IT-CMF): The Body of Knowledge Guide. 2015. Editors. Martin Curley, Jim Kenneally, Marian Carcary. Van Haren Publishing.<br />
<br />
Lessons from Systems Engineering Failures: Determining Why Systems Fail, The State of Systems Engineering Education, and Building an Evidence-Based Network to Help Systems Engineers Identify and Fix Problems on Complex Projects, Diane Constance Aloisio, December 2018.<br />
<br />
===International Standards Guiding EIT===<br />
ANSI/AIAA. 2012. ''ANSI/AIAA Guide to the Preparation of Operational Concept Documents. '' ANSI/AIAA G-043A-2012e.<br />
<br />
IEEE 2012 Std 828™-2012, ''IEEE Standard for Configuration Management in Systems and Software Engineering. ''<br />
<br />
ISO 10004:2012, Quality management—Customer satisfaction—Guidelines for monitoring and measuring<br />
<br />
ISO 10007:2003, Quality management systems—Guidelines for configuration management<br />
<br />
ISO 18238:2015, Space systems—Closed loop problem solving management<br />
<br />
ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models<br />
<br />
ISO/IEC 16350:2015, Information technology—Systems and software engineering—Application management<br />
<br />
ISO/IEC 19770-1:2012, Information technology—Software asset management—Part 1: Processes and tiered assessment of conformance<br />
<br />
ISO/IEC 20000-1:2011, (IEEE Std 20000-1:2013) Information technology—Service management—Part 1: Service management system requirements<br />
<br />
ISO/IEC 20000–2:2012, Information technology—Service management—Part 2: Guidance on the application of service management systems<br />
<br />
ISO/IEC TR 20000–10:2015, Information technology—Service management—Part 10: Concepts and terminology<br />
<br />
ISO/IEC TR 20000–11:2015, Information technology—Service management—Part 11: Guidance on the relationship between ISO/IEC 20000-1:2011 and related frameworks: ITIL®<br />
<br />
ISO/IEC TR 20000-12—Information technology—IT Service management—Part 12: Guidance on the relationship between ISO/IEC 20000-1:2011 and service management frameworks: CMMI-SVC®<br />
<br />
ISO/IEC/IEEE 14764-2006, Software Engineering—Software Lifecycle Processes—Maintenance<br />
<br />
ISO/IEC 15939:2007, Systems and software engineering—Measurement process<br />
<br />
ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description <br />
<br />
<br />
----<br />
<center>[[ Systems Engineering and Economics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Quality Attributes|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Enterprise_IT&diff=66925
Systems Engineering and Enterprise IT
2023-04-24T05:56:04Z
<p>Mhaas: Reference formatting</p>
<hr />
<div>----<br />
'''''Lead Authors:''''' Chuck Walrad and Richard Hilliard<br />
----<br />
This article forms part of the [[Related Disciplines]] knowledge area (KA). It discusses enterprise IT, building upon the concepts and practices of Systems Engineering presented elsewhere in the SEBOK. Systems Engineering is integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of ''engineered technical systems''. <br />
<br />
== Enterprise IT Introduction==<br />
Although it had its origin in the need to improve success rates in U.S. Government outsourcing of technical systems, Systems Engineering is also integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of [https://www.incose.org/about-systems-engineering/system-and-se-definition/systems-engineering-definition#ENGINEERED_SYSTEM engineered technical systems].<br />
Examples of EIT systems include enterprise resource planning, supply chain management and customer relationship management systems, accounting, finance, inventory and order management, marketing, planning, purchasing, and sales.<br />
In the late 1980s and throughout the 1990s, EIT organizations became increasingly aware that the success rates of IT projects were very low, and that their enterprise customers were increasingly unhappy with their EIT investments. The Standish Group sought to understand what was going on. Their findings were presented in the [https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf Chaos Report] (1994):<br />
The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable but could easily be in the trillions of dollars.<br />
As a result, commercial IT organizations, through the auspicious parallel emergence of the Total Quality Management movement and the increasingly widespread development of application development methodologies (ADM) by IT management consulting firms, recognized the need for the principles of Systems Engineering and cross-functional teams (Integrated Product Teams [https://www.sebokwiki.org/wiki/Integrated_Product_Team_(IPT)_(glossary)]. It should be noted that there is considerable overlap today between what constitutes Systems Engineering and what constitutes [[Project and Portfolio Management|Relationships between Systems Engineering and Project Management]] (see [https://www.pmi.org/learning/library/bridging-gap-program-management-systems-engineering-6213 PMI]). This article does not attempt to resolve this issue. Note that the “[[Related Business Activities|following business management activities]] can be ''supported'' by enterprise systems engineering (ESE) activities” [emphasis added]: <br />
* mission and strategic planning,<br />
* business processes and information Management,<br />
* performance management,<br />
* portfolio management,<br />
* resource allocation and budgeting, and<br />
* program and project management.<br />
Note that these same areas have been designated as being supported by Project Management Offices. However, since a key difference between project management and systems engineering has been identified as the requirement that the latter includes technical expertise in the product/system of concern, focus should be on systems engineering and integrated product teams (IPTs). <br />
With IPTs, each product is shepherded from concept through delivery and support to retirement by a cross-functional team that includes representatives from each area of responsibility, such as customer requirements development, design and development, test, configuration management, release engineering, delivery, and support.<br />
As enterprises have come to depend more and more on technology to perform effectively, Enterprise IT organizations have matured, often due to the influence of IT consulting firms that make it their business to keep abreast of best practices.<br />
<br />
== EIT Concepts ==<br />
This knowledge area (KA) discusses enterprise IT, building upon the concepts elucidated in the IEEE/ACM ''[http://eitbokwiki.org EITBOK Guide to the Enterprise Information Technology Body of Knowledge]'' and general concepts of Systems Engineering elsewhere in SEBOK. <br />
An enterprise may be viewed from various perspectives: such as a system or a [[system of systems (SoS)|Enterprise Systems Engineering]]:<br />
* system-like enterprise: enterprises, like other systems, may have a tight coupling, single-executive function; <br />
* system of systems-like enterprise: may be a loosely coupled group of organizations with blurred boundaries and (yet) with (some) shared outcomes.<br />
The choice of perspective may vary with many factors: the enterprise itself, the mission or purpose, or the particular engineering task at hand. We can view an enterprise as a system with inputs and outputs in relation to the outside world, or a system of systems interacting through their individual inputs and outputs. <br />
An enterprise usually involves one (or more) organization(s) but need not be identified with the organization. As the scope of human and organizational participants of the enterprise widen, there may be no single point of control. For example, an ''extended enterprise'' could include a company, its suppliers and customers.<br />
Whatever perspective (system-like, SoS-like, other) is taken there are [[key ingredients|Enterprise Systems Engineering Background]] of any enterprise: capabilities, individual (competencies) and the organizational design. [[Capabilities|Enterprise Capability Management]] can be further categorized: “There are three different kinds of capability: organizational capability, system capability, and operational capability.” These capabilities determine what the enterprise is able to produce which may be external offerings or internal mechanisms. Operational capabilities create services and/or products which in turn produce value as determined by stakeholders. The capabilities of an enterprise are realized through [[Enterprise Systems Engineering Background|various enterprise elements]], including: “hardware, software, personnel, facilities, data, materials, techniques, and even services”. which include “soft” items, like people, processes, principles, policies, practices, organizations, doctrine, theories, and beliefs.<br />
EIT capabilities exist through lifecycles spanning from creation through eventual replacement and disposal. ''Life cycle models'' are schemes to aid in the understanding, design, planning and management of the capability of interest. <br />
“A life cycle for a system generally consists of a series of stages regulated by a set of management decisions which confirm that the system is mature enough to leave one stage and enter another.” Basic life cycle terms and concepts are discussed in [[System Lifecycle Approaches]]. Some typical life cycles are discussed in [[System Lifecycle Models]].<br />
A life cycle-based approach can be deployed across the several levels and used to manage evolution. These levels are:<br />
* the enterprise itself,<br />
* the processes and organizations constituting the enterprise,<br />
* the systems enabling the capabilities, services or products provided. <br />
It is important to distinguish between ''product'' and ''project'' lifecycle models. A product’s life cycle extends from its initial concept approval, through development and distribution, to its retirement. This is the cycle that is managed within an Enterprise IT organization, since EIT must manage the hardware or software product from its introduction, in the case of acquired capabilities, or from its concept approval and development, in the case of capabilities it builds, through its deployment, maintenance and eventual retirement (withdrawal). Each of these stages is usually managed as a project or a series of projects.<br />
However, most discussions of life cycles within software and systems discussions focus on ''project'' life cycles. See, for example, the ''Software Extension to PMBOK Guide'' (PMI 2013).<br />
==System of Systems Context in EIT==<br />
“Enterprise IT” (EIT) is used both to refer to the technology organization/business unit within the enterprise and to the enterprise’s information technology systems. In this article, we use EIT to refer to the technology systems. When referring to the organization, we use the phrase “Enterprise IT organization” or EIT organization. <br />
Enterprise IT organizations are responsible for complex socio-technical systems. Socio-technical systems in a business context (thus, EIT) contain technical elements (software, hardware, networks, storage, databases, etc.) but they also contain essential human components and necessary business processes. As covered in [[Introduction to Systems Engineering Fundamentals]], they exist in an engineered System Context that is a set of system component interrelationships within a real-world environment:<br />
This includes where problems come from and how they are defined, how we identify and select candidate solutions, how to balance technology and human elements in the wider solution context, how to manage the complex organizational systems needed to develop new solutions, and how developed solutions are used, sustained and disposed of. … Systems Engineering should consider the full Engineered System Context so that the necessary understanding can be reached and the right systems engineering decisions can be made. <br />
Socio-technical systems also have the following key characteristics: ''Openness'' in that they strongly interact with their environments, and ''unfinished'' in that they evolve over time.<br />
A complex of EIT systems is essential to the successful functioning of the humans in the enterprise. They rely on EIT’s technology for communication, for paying employees, for people management, for business measurement, and often for managing supply chains. Thus, “EIT needs to be viewed as a strategic partner to all the other functions and business units within an enterprise. This means that the results produced by EIT along with its effectiveness and efficiency are all critically important to the success of the enterprise.” [http://eitbokwiki.org/What_is_the_Enterprise_Perspective%3F]<br />
To accomplish this mission, the EIT organization builds and acquires new systems or system components, integrates them into the mega System of Systems, and maintains the integrity and interoperability of the individual components, but also the integrity of the entire complex of systems. In addition, security and performance levels must be achieved, benchmarked and maintained or improved.<br />
==Major concerns of the EIT Organization==<br />
The [http://eitbokwiki.org ''Enterprise IT Body of Knowledge''] provides a good deal of information about these major concerns, which we will not replicate here. Rather, links to the relevant areas are provided. The EITBOK demonstrates how, in providing technology systems and services to the enterprise, the EIT organization must skillfully manage such concerns as the following.<br />
<br />
===Enterprise Architecture===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Enterprise_Architecture Enterprise Architecture] for additional information. ''<br />
[http://eitbokwiki.org/Glossary#ea ''Enterprise architecture''] (EA) is the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. EA applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their organization's strategies. Enterprise architecture builds upon many of the concepts and practices of [[System Architecture Definition|systems architecture]] and also software architecture [https://www.sebokwiki.org/wiki/System_Architecture_Definition].<br />
This section will discuss Enterprise Architecture from the perspective of key [[Principles of Systems Thinking]], designated in this article with '''''bold italics'''''. There are many commonalities in architecture whether one is architecture systems, software or the enterprise [Unity]. In this article we highlight both commonalities and differences between Enterprise Architecture and Systems Architecture. <br />
Architecture takes place at the juncture of design problems and their solutions. Design problems rarely arrive fully formulated or “hatched” for the architect; much of the architecture effort is to analyze or formulate the problems to be solved. Often this involves negotiation both within the enterprise and with outside stakeholders. Possible solutions are limited by resources and schedule and therefore often must also be negotiated.<br />
A dominant principle of Enterprise Architecture is '''''separation of concerns''''' (SoC). This is due to the complexity of enterprises, with many forces acting upon them; the many technologies and disciplines involved in their creation and day-to-day operations; and due to the diversity of stakeholders involved in the enterprise (see [[EIT Roles]]). <br />
An application of SoC is the '''''boundary''''' principle which is crucial to separate what is “inside” the enterprise from what is “outside”. While the former is often under the enterprise’s control, the latter is often beyond its control. <br />
For some systems, determining the boundary is a key decision, subject to many possibilities and consequences. This is perhaps less the case for enterprises whose bounds are determined by the extent of organizations, regulations, supply chains or other criteria. Within an established boundary, the '''''holism''''' principle applies: to treat the enterprise as a unified whole, and, in particular, with respect to the '''''interaction''''' of the enterprise with its ''environment''—including stakeholders, other enterprises and systems. From an enterprise IT perspective, an enterprise is a ''system of systems. '' SoC offers a way to focus on the constituent systems in terms of their interconnections to one another to form the enterprise.<br />
Another useful application of SoC is to apply the principle of '''''multiple views''''' to depict the architecture of the enterprise in different ways to address the diverse interests (i.e., ''concerns'') of an enterprise’s various stakeholders. Each ''architecture view'' presents a specific perspective on the enterprise. To be understandable to its audiences (those various stakeholders), each view should follow the conventions of its ''architecture viewpoint'' (ISO/IEC/IEEE 42010 2011). Just as a map should have a legend, each view should have a documented viewpoint providing a prescribed set of conventions for looking at the enterprise through the resulting view. A viewpoint definition serves as a contract between the architect and stakeholders on ''how'' a selected set of concerns are to be addressed. Each viewpoint allows the architect to consider the enterprise in terms of various kinds of elements and relations among them and to present that view to those “concerned” stakeholders. Dominating concerns in enterprise architecture include interoperability, quality of systems and services, operations, managing change, and alignment with the enterprise’s mission, market, and technology. Via the principle of '''''dualism''''', we recognize that some viewpoints are paired, such as with process/data duality. Another pervasive duality in the enterprise is of people/technology in terms of what capabilities are automated and which are performed by people.<br />
In support of enterprise architecture, there are numerous ''enterprise architecture frameworks'' each providing a pre-defined, integrated set of viewpoints to frame typical, recurring concerns (ISO/IEC/IEEE 42010 Users Group 2022). The earliest recorded framework was (Hammer et al. 1986), developed in the mid-1980s in response to growing availability of distributed computing to the enterprise (Rivera 2013). In the late 1980s, US NIST created its Enterprise Architecture Model as a guide for US federal departments to organize their IT offerings (Fong and Goldfine 1989). NIST’s 5-layer model remains influential today. Despite never using the term “enterprise,” Zachman’s information systems architecture has had a major influence on how subsequent frameworks have been organized and depicted using grids or cubes. Later frameworks have evolved in response to emerging concepts, such as the move from client-server to service-oriented applications, as in the OASIS SOA Reference Model and its associated framework. The 1990s saw a proliferation of frameworks for defense enterprises including US DODAF, UK MODAF, NATO’s NAF and led to successors such as OMG’s UAF.<br />
Yet another application of '''''separation of concerns''''' is distinguishing today’s needs versus facilitating future needs; balancing '''''stability/change''''' and highlighting the temporal planning aspect of architecture of the enterprise. In concert with applying SOC, the architect uses the principle of '''''abstraction''''' to “forget” some details of the subject and thus focus on essentials. Just as SoC is a way of taking things apart, '''''abstraction''''' is a way of unifying or putting like things together through generalization. These two principles are perhaps the most central to architecture. SoC and abstraction work together: SoC picks out subjects and abstraction helps architects to focus upon the essentials of each subject. <br />
Returning to the '''''boundary''''' and '''''holism''''' principles, the enterprise architect applies these recursively. As architecting proceeds, the internal details of the enterprise become known in terms of '''''interaction''''' among its parts and other '''''relations'''''. Again, '''''multiple views''''' are used to factor specific '''''relations'''''into distinct views. Typical relations include Causality, Dependency, Client-Server, and Input-Output. <br />
There are a variety of ways to structure the enterprise based upon stakeholder needs, mission or charter, technologies or capabilities already in place. Among these are structuring principles including: <br />
* '''''Modularity''''' (separate and group capabilities into modules by commonalities); <br />
* '''''Network''''' (modules are linked together); <br />
* '''''Encapsulation''''' (separating architecture modules use from how they are implemented); <br />
* '''''Layer Hierarchy''''' (separation through gradual refinement); <br />
* ''''' Regularity''''' (uniformity of interactions, of structure within layer, within network). <br />
* ''''' Similarity/Difference''''' (recognizing the limits of Regularity)<br />
A simple pattern for architecture has been defined (Hofmeister ''et al. '' 2007). Its elements are Analysis, Synthesis and Evaluation. See Figure 1 below. <br />
''Architecture Analysis'' formulates architecturally-significant requirements (ASRs)—those requirements which influence an enterprise’s architecture. Architecture analysis is based on identified concerns and other information based on understanding the enterprise’s environment, known requirements, stakeholder needs and any constraints. ASRs reflect the “design problems” that the architecture must solve. In many cases, negotiations take place to modify incoming needs, requirements and expectations to make solutions possible. The result of this activity takes the form of ASRs, including architecture principles and initial enterprise-wide decisions.<br />
''Architecture Synthesis'' develops candidate solutions in response to the concerns and ASRs. During Synthesis the architect works out the details of solutions to the identified design problems, tradeoff and interactions between them which are likely to generate further design problems. Synthesis elaborates the ASRs, principles and initial decisions into more detailed solution elements. The principle of ''''' EQUIFINALITY''''' reminds us that for many stable situations (i.e., states of the enterprise), there are many ways to reach those states.<br />
''Architecture Evaluation'' validates whether chosen solutions satisfy ASRs or whether rework is needed (ISO/IEC/IEEE 42030 2019).<br />
Applying the principles discussed above is pervasive in enacting the Analysis–Synthesis–Evaluation pattern iteratively. <br />
<br />
<br />
Figure 1 A pattern for Architecture<br />
While there are many commonalities among EIT, systems and software architectures, Figure 2 addresses the relationships ''between'' them. Viewing an enterprise as a system, the EIT architecture governs the fundamental IT decisions of the enterprise. That enterprise might be extended to “outsiders” such as vendors, suppliers and perhaps customers. Depending upon the enterprise, the ''governs'' relationship may entail very strict rules or loose guidance. <br />
Within the enterprise, the ecosystem of systems, applications and data may be viewed as a system of systems. The EIT Architecture constrains the architectures governing individual systems, applications and data stores within the enterprise, so that these are able to interoperate and otherwise “play nicely” together.<br />
<br />
Figure 2 Relating Enterprise IT, Systems and Software Architecture<br />
===Strategy and Governance===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance] for additional information. ''<br />
{{Blockquote<br />
|text= [http://eitbokwiki.org/Glossary#eit Enterprise information technology] (EIT) governance is the established process of defining the strategy for the EIT organization and overseeing its execution to achieve enterprise goals. Strategic planning translates the larger enterprise’s goals into EIT goals and defines what EIT must do to achieve those goals. This effort then communicates this hierarchy of goals: EIT goals as well as how they support the enterprise’s goals. EIT governance drives needed changes to achieve those goals, while maintaining agreed levels of operation. Taking into account various perspectives (such as financial, historical, environmental, and future projections), a strategic plan is a roadmap for action and change, both vertically and horizontally, across the EIT organization. The EIT organization’s strategic plans are based on the enterprise’s strategic plans, focusing on EIT’s role in them; EIT governance provides a monitoring and control framework to achieve strategic goals and objectives. Thus, EIT governance is essential for achieving the EIT strategy and goals..<br />
|author=[http://eitbokwiki.org/Strategy_and_Governance EITBOK wiki]<br />
}}<br />
<br />
The principle of ''''' PARSIMONY''''' applies here, too (see [[Principles of Systems Thinking]]). These principles will be designated in this article with '''''bold italics'''''. For example, the simplest possible measurement and reporting systems are most likely to be used and not corrupted. Similarly, the EIT organizational structure should be straightforward and easy to traverse so that staff can communicate and problem-solve in teams.<br />
In governing the EIT organization to meet its dual goals of satisfying its customers and meeting its budget and schedule commitments, EIT management encounters the difficulty of managing in the face of '''''dualism''''', “ensuring a constant dynamic balance often through a cyclic dominance of one element and then the other”. The most obvious instance of handling ''''' dualism''''' in EIT is the trade-off between budget, project prioritization and features within projects.<br />
===Change===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Change_Initiatives Change Initiatives] for more information. ''<br />
There are two levels of change management discussed in the EITBOK: organizational change management and changes to the IT organization’s assets, whether they be software, hardware, or telecommunications systems.<br />
In the larger sense, the introduction of new systems and services often also requires changes in people’s jobs and in the processes used to accomplish those jobs. Such efforts are intended to increase business value. Such changes require change initiatives because they involve guiding a mixture of stakeholders through the change process. This is one aspect of [http://eitbokwiki.org/Change_Initiatives change management].<br />
Change also occurs when existing systems or services must be updated to meet new needs. Depending on the scope of the proposed changes, a change initiative may be required in this situation, too. At any rate, a change request process must be initiated and tracked to disposition (deferral, rejection, or implementation). Changes also come about as a result of defect reports. In such cases, the defect report must be tracked throughout the report’s life cycle, to disposition (deferral, rejection, or implementation).<br />
These latter types of change management are discussed in detail in the EITBOK’s section on [http://eitbokwiki.org/Operations_and_Support Operations and Support].<br />
===Interoperability of Component Systems===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Interoperability interoperability] for more information. ''<br />
As explained in the [http://eitbokwiki.org/Interoperability#One EITBOK], ''interoperability'' means “the ability of systems (including organizations) to exchange and use exchanged information without knowledge of the characteristics or inner workings of the collaborating systems (or organizations).” This definition is based on an ISO definition: “degree to which two or more systems, products, or components can exchange information and use the information that has been exchanged.” (ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models, 4.2.3.2. ) Note that this definition includes hardware components as well as software systems and the organizations in which they are used.<br />
Because technology changes so rapidly, and organizations themselves are frequently changing, achieving and maintaining interoperability is crucial. It is one of the main reasons that providing IT services is difficult and how it differs from engineering and delivering finished products, whether off-the-shelf products or bespoke systems.<br />
===Security of Systems and Data===<br />
{{Blockquote<br />
|text=There are only two types of companies: those that have been hacked, and those that will be.<br />
<br />
|author= FBI Director Robert Mueller, October 2012<br />
}}<br />
{{Blockquote<br />
|text= There are two kinds of big companies in the United States. There are those who've been hacked by the Chinese and those who don't know that they've been hacked by the Chinese.Quoted material.<br />
|author=FBI Director James Comey, October 2014<br />
}}<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Security security] for additional information. ''<br />
While there are many definitions for security, most include the three dimensions of confidentiality, integrity, and availability (sometimes referred to as the [http://eitbokwiki.org/Glossary#ciatriad CIA triad]). As such, the primary goal of EIT security is to preserve the confidentiality, integrity, and availability of information and information systems. <br />
The principles behind an organization’s [http://eitbokwiki.org/Glossary#isms information security management system] (ISMS) should be to design, implement, and maintain a coherent set of policies, processes, and systems that keep the risks associated with its information assets at a tolerable level, and yet, manage the cost and inconvenience of said risk management. As such, the goals of EIT security are to:<br />
* Always understand the current risk tolerance of the enterprise with respect to information and device security.<br />
* Understand the security threats and potential damages to information, devices, and individuals.<br />
* Create and follow policies and procedures that keep cyberattack risk and damages at or below a tolerable level.<br />
* Effectively and efficiently detect and deal with<br />
[http://eitbokwiki.org/Security#One cyberattack incidents].<br />
Ensuring security in EIT has been made even more pressing and more difficult by the proliferation of mobile devices in enterprises and their ever-increasing use to conduct business. Increasingly, personal devices (Bring Your Own Device – BYOD) are used, accessing both corporate networks and public networks. The cost of [https://www.checkpoint.com/downloads/products/check-point-mobile-security-survey-report2013.pdf mobile security incidents] very easily can outweigh the cost of the mobile device itself. <br />
==Quality of Systems and Services==<br />
The Enterprise ''Information'' Technology organization has, since its origins, had as its primary responsibility the timely provision of information to the larger organization. The information is expected to be not only timely, but also accurate and relevant. While the EIT organization itself may not be responsible for creating the data, it is responsible for the physical and logical validity and [https://simplicable.com/new/data-integrity-vs-data-quality integrity of the data] that is used to construct information. It is for this reason that defining and using appropriate processes is essential to ensure high-quality operation, including the development or acquisition, implementation and integration of new or changed capabilities.<br />
The EITBoK details the quality concepts of<br />
* How to approach measuring [http://eitbokwiki.org/Quality#Measuring_Quality Quality]<br />
* The importance of Quality in [http://eitbokwiki.org/Quality#Requirements_Management Requirements Management]<br />
* Understanding an organization’s [http://eitbokwiki.org/Quality#Quality_Capability Quality Capability]<br />
* The differences between [http://eitbokwiki.org/Quality#QMS_and_QC_vs._QA QMS, QC and QA]<br />
* Cost of Quality in [http://eitbokwiki.org/Quality#Technical_Debt_and_the_Cost_of_Rework Technical Debt and the Cost of Rework]<br />
==Disaster Preparedness==<br />
<br />
As explained in the [http://eitbokwiki.org/Disaster_Preparedness EITBOK], disaster preparedness and [http://eitbokwiki.org/Glossary#dr disaster recovery] (DR) support business-continuity planning and include planning for EIT resiliency, as well as recovery from adversity, so that critical business services affected are restored to a satisfactory working state within an [http://eitbokwiki.org/Glossary#acceptable acceptable] timeframe after an event.<br />
The EITBoK devotes a chapter to how the EIT organization and its parent must plan in advance for how it will provide sufficient organizational resilience to recover from disasters and return to normal operation as rapidly as possible.<br />
It provides the following examples of disasters and service interruptions that could occur and should be considered in prevention and recovery planning:<br />
These are examples of disasters:<br />
* Natural disaster affecting datacenters or EIT service operations (flood, fire, earthquake, wind)<br />
* Security breach resulting in a disaster (destruction of data, admin password changes, virus/malware installation, sabotage)<br />
* Usage error (accidental deletion, unplug/turn off system resulting in corruption)<br />
* Utility failure affecting datacenters (loss of power even after UPS)<br />
* Vendor failure (cloud provider security failure, oil spill)<br />
* Staffing issue (employment dispute/walkout, epidemic)<br />
These are examples of unpreparedness:<br />
* Requiring use of computers or printers when power is out<br />
* Requiring use of Internet when power or connectivity is out<br />
* Single point of knowledge/control for administration access<br />
* Lack of offsite backup storage<br />
* Lack of working restoration from backups<br />
* Lack of failover datacenters in separate locations<br />
* Undocumented or out-of-date documentation for system interfaces<br />
*Requiring use of phones that are out of power<br />
* Lack of designation of leaders in restoration efforts (who is in charge of restoring service and they know they are in charge)<br />
* In general, no cohesive, comprehensive EIT service restoration plan<br />
==Operations and Support of Delivered Systems and Services==<br />
[http://eitbokwiki.org/Operations_and_Support Operations and support activities] focus on maintaining an operation normal state in EIT environments, meaning that systems and processes execute according to expectations, with no surprises to users. This desired normal state requires the careful management of EIT assets and services via Operations, as well as of users via Support.<br />
Normal states can be disrupted either by the expected and planned transition of an asset, or by an unexpected event, be it as large as a disaster or by the discovery of a system defect. In the former case, the Disaster Recovery Plan is executed; in the latter, incident management kicks in when a system halts, or problem management is exercised when an operational system is not functioning as expected. The processes needed to ensure effective application of these complex functions is detailed in the [http://eitbokwiki.org/Operations_and_Support#Guiding_Principles Operations and Support Knowledge Area] within the EITBOK. <br />
ISO/IEC/IEEE 20000 may be used by any organization to develop and manage EIT operations, along with the current version of [https://www.servicenow.com ITIL].<br />
ITIL for many is the tool of choice for the operations and infrastructure side of IT, particularly for IT services. <br />
==Ethics==<br />
See the EITBOK’s section on [http://eitbokwiki.org/Ethics ethics] for additional information.<br />
Both the IEEE and ACM require their members to adhere to Codes of Ethics. See the [https://www.ieee.org/about/corporate/governance/p7-8.html IEEE Code of Ethics] and [https://www.acm.org/code-of-ethics ACM Code of Ethics and Professional Conduct]. Both of these can be downloaded freely. In addition, the IEEE Computer Society and the ACM worked together on the [https://dl.acm.org/action/downloadSupplement?doi=10.1145%2F265684.265699&file=acm-se-code-of-ethics.html Software Engineering Code of Ethics] (also available [https://dl.acm.org/doi/10.1145/265684.265699 here]).<br />
The organization should create an easily accessible Code of Ethics:<br />
* Ethical assertions should be documented and socialized in EIT in the form of a Code of Ethics, tied to the overall business code of ethics, and signed off by all staff so that violations can be cause for reprimand or dismissal.<br />
* Vendors should be held to similar ethical standards.<br />
* Lists of employees who have signed off on the Code of Ethics are maintained by EIT governance.<br />
The EITBOK has identified EIT ethical topics that include:<br />
* Those actions and decisions that may be illegal<br />
* Consideration of the social impact of the work at hand—if it will cause harm<br />
* Alignment of business and EIT strategies and policies to an ethical standard<br />
* Incorporation of the ideals of professionalism<br />
* Adherence to applicable regulatory intent<br />
* Protection for whistle blowers<br />
Areas to specifically highlight:<br />
* Activities that interfere with or corrupt the proper function of computers, applications and systems<br />
* Activities that interfere with digital privacy or intellectual rights of others<br />
* Respect for confidentiality, privacy, permissions, and access rights<br />
* Inappropriate bias (skewing) of analysis and reporting<br />
* Inaction in the face of likely ethics violations<br />
==EIT Roles==<br />
Several roles play a part in accomplishing the EIT organization’s mission. Just as a systems engineer can play several roles in a given project, so might several people in an EIT project combine to fulfill the systems engineering function. <br />
The function of EIT systems engineering is to orchestrate systems development, delivery and operation such that the larger organization achieves favorable outcomes in complex environments. Unlike systems projects that are built for known problems, EIT systems may change in unpredictable ways. A primary concern focuses on how quickly systems adapt to change. This entails a type of resiliency based on skills in establishing options and alternative solutions as well as strategies tailored to the volatility of changing needs and available technologies. It also requires expertise in assuring that systems quality is assured from the start.<br />
Different countries, geographic areas and organizations do not always use the same terminology to reference the functions that the roles contributing to systems engineering perform. The following section will provide information about some major international models for defining EIT skills and capabilities. Generally, though, the necessary roles across the product life cycle include these:<br />
* Business Sponsor/Champion<br />
* Enterprise Architect<br />
* Systems Engineer<br />
* Financial Manager<br />
* Application Architect<br />
* Business Analyst and/or Process Analyst<br />
* Data Analyst and/or Data Architect<br />
* Software Engineer and/or Programmer<br />
* Quality Assurance & Testing<br />
* Network Engineer<br />
* Telecoms Engineer<br />
* Integration Expert <br />
* Transition to Operations Manager<br />
* Release Manager<br />
* Availability Manager<br />
* Capacity Manager<br />
* Change Manager<br />
* Configuration Manager<br />
* EIT Operations Manager<br />
* Incident Management<br />
* Problem Manager<br />
* Service Level Manager<br />
* Database Administrator<br />
* Network Manager<br />
* Product Manager<br />
System engineering activities orchestrate the work of these roles so that they function together, rather than in silos or at cross purposes.<br />
==Examples of Systems Engineering in EIT==<br />
Systems Engineering provides a holistic discipline for integrating and managing the contributions of all roles needed to establish and provide EIT products and services. It ensures that a single perspective does not dominate outcomes; instead, it seeks balance among the many disciplines represented above in creating a consistent product or service that meets the interests and needs of enterprise users (and, perhaps, partners). It boils down to common sense, technical sense, knowing when to ask the right questions, and getting the data to support the answers to those questions. System Engineering achieves this via Systems Engineers. In many instances, though, the SE function is accomplished through Project Management approaches using Integrated Product Teams that include technical experts. Thus, although not specifically calling out a Systems Engineering function, the use of IPTs involved the use of SE practices.<br />
A doctoral dissertation from Purdue University performed a survey and causal analysis of project failures and of accidents(Aloisio, 2018). The results were similar to those found in reviews of IBM consulting projects in the 1990s . The following are examples of Systems Engineering interventions that prevented project failures. Almost all point to the lack of the System Engineering balancing act needed for product delivery.<br />
* A widely used document processing product was undergoing a major upgrade. The new VP of Engineering wanted a project review before committing to a schedule. The review showed that the proposed schedule only considered the development effort and did not give sufficient weight to the voices of the testing and documentation organizations, while the needs of the tech support group had been completely overlooked. By establishing an integrated product management team that included technical expertise, as well as expertise in work breakdown and estimating, a realistic effort was defined and the resulting 9-month schedule was met within 3 weeks.<br />
* A Silicon Valley start-up was depending entirely on an offshore development effort to produce its first product. All senior management was in the U.S. The VP of engineering made monthly visits to the development team. The CEO began to feel uneasy about the team’s ability to deliver on schedule sensing that a lot of finger pointing within the development team itself signaled problems. There was no SE or IPT guiding the project. The VP of Engineering seemed unable to sort things out. A project review showed that the probable delivery date was at least 6 months beyond what the CEO was being told. The project was shut down.<br />
* A major player in Human Resource Management had made commitments to deliver a new product. The project involved more than 100 people across the U.S. The delivery date kept slipping. Project roll-out would involve both installation of software and hardware at client sites, as well as installation and staff training at the large, centrally located Client Services organization. Executive Management needed to decide whether to reorganize this very expensive effort or cancel it. Again, the successful solution depended on establishing an effective cross-functional team (IPT) that necessarily included representatives from the technical teams. The IPT was supported by a newly established Project Management Office (PMO). The PMO integrated the geographically disparate efforts by establishing communication channels, as well as common estimating and scheduling practices. The PMO also instituted monthly critical metrics reports to show the IPT bottlenecks and inefficiencies across the project, from development efforts to Client Services set-up to Payroll technical support.<br />
There are far more examples of the lack of systems engineering practices in EIT projects than in their successful use (unfortunately, this seems also to be true in lots of software projects outside of EIT). Systems Engineering provides a holistic discipline for integrating and managing the contributions of all of the roles needed to provide EIT products and services. It ensures that a single perspective does not dominate outcomes.<br />
==Key External Models of EIT Organizational Capability and Maturity==<br />
Because EIT is critical to businesses globally, considerable effort has gone into establishing universal frameworks for EIT skills, along with definitions of levels of capability of each skill. In addition, at least 2 models have been developed for evaluating the organizational performance of EIT. The effectiveness of systems engineering is key to the effectiveness of the EIT organization.<br />
===IT-CMF: IT-Capability Maturity Framework=== <br />
The IT-CMF had its origin in a quality improvement effort at Intel Labs Europe in Ireland. Its intent, as described at the <br />
[https://cio-wiki.org/wiki/IT_Capability_Maturity_Framework_(IT-CMF) CIO Index website] was to quantify and demonstrate the true value impact of IT. IT-CMF is used to measure, develop, and monitor an organization’s EIT capability maturity. It consists of 35 EIT management capabilities organized into four macro capabilities: managing EIT like a business; managing the EIT budget; managing the EIT capability; and managing EIT for business value. Its 35 critical capabilities (CCs) are [http://eitbokwiki.org/Enterprise_IT_Maturity_Assessment described] as “A defined EIT management domain that helps mobilize and deploy EIT-based resources to effect a desired end, often in combination with other resources and capabilities”. <br />
===CMMI: Capability Maturity Model Integration (US)===<br />
The CMMI had its origin in 1987 in a model requested by the U.S. Department of Defense for determining the capability maturity of contractor software development organizations. This became the Capability Maturity Model (CMM). Since then, it has been expanded into a set of Capability Maturity Models, all based on five levels of demonstrably increasing maturity as measured by organization performance. That set was then integrated and became the CMMI. The CMMI set addresses [https://cmmiinstitute.com/dev Development], [https://cmmiinstitute.com/svc Services], [https://cmmiinstitute.com/sm Supplier Management], [https://cmmiinstitute.com/pm People Management], and [https://cmmiinstitute.com/dm Data Management].<br />
===SFIA: Skills Framework for the information Age (Europe, Canada and US)===<br />
The SFIA Framework has been downloaded and used by organizations and individuals in nearly 180 countries. It can be downloaded for free at [https://www.sfia-online.org]. It identifies 97 professional skills across EIT and supporting areas with seven levels of responsibility, which provide generic levels of responsibility, taking into account reflect experience and competency. These describe the behaviors, values, knowledge, and characteristics that an individual should have in order to be considered competent at a particular level.<br />
===E-CF: European Competency Framework (EU)===<br />
The ECF was the first sector-specific implementation of the European Qualifications Framework (EQF). The European Norm (EN) 16234-1 European e-Competence Framework (e-CF) provides a reference of 41 competences as applied at the Information and Communication Technology (ICT) workplace, using a common European reference for competences, skills, knowledge and proficiency levels. The E-CF Explorer web tool is available [https://ecfexplorer.itprofessionalism.org/ online].<br />
===I Competency Dictionary: EIT skills as Defined by METI/ IPA (Japan)===<br />
The Japanese government’s Information-Technology Promotion Agency (IPA), established by the Ministry of Economy, Trade and Industry (METI) developed the ”I Competency Dictionary” (iCD) to support the IT Engineers Examination. It underlies the METI/IPA Skills Standards for IT Professionals, abbreviated as ITSS, established in 2002. ITSS organizes skills within the information services industry into 11 job categories and 35 specialty fields. In each field, there are seven levels of competence based on individual experience and ability to perform. One appealing feature of ITSS is that this standard allows engineers to draw roadmaps for their own futures and career advancement (Career Path). Approximately 90% of large enterprises and over 60% of SMEs in Japan have introduced or are considering using ITSS. Information in English is available at https://www.ipa.go.jp/english/humandev/forth.html.<br />
===ITIL: Information Technology Infrastructure Library===<br />
According to ITLIlibrary.org, the ITIL Open Guide website, “The Information Technology Infrastructure Library (ITIL) defines the organisational structure and skill requirements of an information technology organisation and a set of standard operational management procedures and practices to allow the organisation to manage an IT operation and associated infrastructure. … The [https://www.itlibrary.org/ “library”] itself continues to evolve. This comprises five distinct areas: <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Strategy ITIL Service Strategy]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Design ITIL Service Design]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Transition ITIL Service Transition]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Operation ITIL Service Operation]; and <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Continual_Service_Improvement ITIL Continual Service Improvement].”<br />
It originally grew out of a British government sponsored effort to regularize IT Service Management (ITSM). <br />
==References==<br />
===Works Cited===<br />
Fong, E.N. and A.H. Goldfine. 1989. ''Information Management Directions: The Integration Challenge. '' National Institute of Standards and Technology (NIST) Special Publication 500-167, September 1989. https://csrc.nist.rip/library/NIST%20SP%20500-167.pdf <br />
<br />
Hammer, M., T.H. Davenport and J. Champy. 1986. ''Dispersion and Interconnection: Approaches to Distributed Systems Architecture'', Cambridge, MA: CSC Index Inc. and Hammer and Company, Inc. (June 1986). Available as: https://www.globalaea.org/general/custom.asp?page=Resources <br />
<br />
Hilliard, R. 2015. “Lessons from the fundamental unity of architecting”. ''Software Engineering in the Systems Context'', editors: Ivar Jacobson and Harold 'Bud' Lawson.<br />
<br />
Hofmeister, C. et al. 2007. “A general model of software architecture design derived from five industrial approaches”. ''The Journal of Systems and Software'' 80(1). <br />
<br />
ISO/IEC 25010:2011 ''Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models'', 4.2.3.2.<br />
<br />
ISO/IEC/IEEE 42010 Users Group. ''Survey of Architecture Frameworks'' Available as: http://www.iso-architecture.org/42010/afs/<br />
<br />
ISO/IEC/IEEE. 2011. ISO/IEC/IEEE 42010:2011, ''Systems and software engineering — Architecture description. ''<br />
<br />
PMI. 2013. ''Software Extension to PMBOK® Guide – Fifth Edition. '' Newtown Square, PA, USA: Project Management Institute (PMI). Available as: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/software-extension-5th-edition.<br />
<br />
Rivera, R. 2013. “The PRISM Architecture Framework – Was it the Very First Enterprise Architecture Framework?” ''Journal of Enterprise Architecture'', November 2013<br />
<br />
Zachman, J. 1987. “A Framework for Information Systems Architecture”. ''IBM Systems Journal'', pp454-470, 1987 <br />
<br />
==Primary References==<br />
IEEE Computer Society. ''Enterprise IT Body of Knowledge''. Available: http://eitbokwiki.org<br />
<br />
==Additional References==<br />
IT Capability Maturity Framework (IT-CMF): The Body of Knowledge Guide. 2015. Editors. Martin Curley, Jim Kenneally, Marian Carcary. Van Haren Publishing.<br />
<br />
Lessons from Systems Engineering Failures: Determining Why Systems Fail, The State of Systems Engineering Education, and Building an Evidence-Based Network to Help Systems Engineers Identify and Fix Problems on Complex Projects, Diane Constance Aloisio, December 2018.<br />
<br />
==International Standards Guiding EIT==<br />
ANSI/AIAA. 2012. ''ANSI/AIAA Guide to the Preparation of Operational Concept Documents. '' ANSI/AIAA G-043A-2012e.<br />
<br />
IEEE 2012 Std 828™-2012, ''IEEE Standard for Configuration Management in Systems and Software Engineering. ''<br />
<br />
ISO 10004:2012, Quality management—Customer satisfaction—Guidelines for monitoring and measuring<br />
<br />
ISO 10007:2003, Quality management systems—Guidelines for configuration management<br />
<br />
ISO 18238:2015, Space systems—Closed loop problem solving management<br />
<br />
ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models<br />
<br />
ISO/IEC 16350:2015, Information technology—Systems and software engineering—Application management<br />
<br />
ISO/IEC 19770-1:2012, Information technology—Software asset management—Part 1: Processes and tiered assessment of conformance<br />
<br />
ISO/IEC 20000-1:2011, (IEEE Std 20000-1:2013) Information technology—Service management—Part 1: Service management system requirements<br />
<br />
ISO/IEC 20000–2:2012, Information technology—Service management—Part 2: Guidance on the application of service management systems<br />
<br />
ISO/IEC TR 20000–10:2015, Information technology—Service management—Part 10: Concepts and terminology<br />
<br />
ISO/IEC TR 20000–11:2015, Information technology—Service management—Part 11: Guidance on the relationship between ISO/IEC 20000-1:2011 and related frameworks: ITIL®<br />
<br />
ISO/IEC TR 20000-12—Information technology—IT Service management—Part 12: Guidance on the relationship between ISO/IEC 20000-1:2011 and service management frameworks: CMMI-SVC®<br />
<br />
ISO/IEC/IEEE 14764-2006, Software Engineering—Software Lifecycle Processes—Maintenance<br />
<br />
ISO/IEC 15939:2007, Systems and software engineering—Measurement process<br />
<br />
ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description <br />
<br />
<br />
----<br />
<center>[[ Systems Engineering and Economics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Quality Attributes|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Enterprise_IT&diff=66924
Systems Engineering and Enterprise IT
2023-04-24T05:54:18Z
<p>Mhaas: Adding paper content</p>
<hr />
<div>----<br />
'''''Lead Authors:''''' Chuck Walrad and Richard Hilliard<br />
----<br />
This article forms part of the [[Related Disciplines]] knowledge area (KA). It discusses enterprise IT, building upon the concepts and practices of Systems Engineering presented elsewhere in the SEBOK. Systems Engineering is integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of ''engineered technical systems''. <br />
<br />
== Enterprise IT Introduction==<br />
Although it had its origin in the need to improve success rates in U.S. Government outsourcing of technical systems, Systems Engineering is also integral to the effective functioning of Enterprise IT (EIT) organizations, whose work is devoted to the successful realization, use, and retirement of [https://www.incose.org/about-systems-engineering/system-and-se-definition/systems-engineering-definition#ENGINEERED_SYSTEM engineered technical systems].<br />
Examples of EIT systems include enterprise resource planning, supply chain management and customer relationship management systems, accounting, finance, inventory and order management, marketing, planning, purchasing, and sales.<br />
In the late 1980s and throughout the 1990s, EIT organizations became increasingly aware that the success rates of IT projects were very low, and that their enterprise customers were increasingly unhappy with their EIT investments. The Standish Group sought to understand what was going on. Their findings were presented in the [https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf Chaos Report] (1994):<br />
The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable but could easily be in the trillions of dollars.<br />
As a result, commercial IT organizations, through the auspicious parallel emergence of the Total Quality Management movement and the increasingly widespread development of application development methodologies (ADM) by IT management consulting firms, recognized the need for the principles of Systems Engineering and cross-functional teams (Integrated Product Teams [https://www.sebokwiki.org/wiki/Integrated_Product_Team_(IPT)_(glossary)]. It should be noted that there is considerable overlap today between what constitutes Systems Engineering and what constitutes [[Project and Portfolio Management|Relationships between Systems Engineering and Project Management]] (see [https://www.pmi.org/learning/library/bridging-gap-program-management-systems-engineering-6213 PMI]). This article does not attempt to resolve this issue. Note that the “[[Related Business Activities|following business management activities]] can be ''supported'' by enterprise systems engineering (ESE) activities” [emphasis added]: <br />
* mission and strategic planning,<br />
* business processes and information Management,<br />
* performance management,<br />
* portfolio management,<br />
* resource allocation and budgeting, and<br />
* program and project management.<br />
Note that these same areas have been designated as being supported by Project Management Offices. However, since a key difference between project management and systems engineering has been identified as the requirement that the latter includes technical expertise in the product/system of concern, focus should be on systems engineering and integrated product teams (IPTs). <br />
With IPTs, each product is shepherded from concept through delivery and support to retirement by a cross-functional team that includes representatives from each area of responsibility, such as customer requirements development, design and development, test, configuration management, release engineering, delivery, and support.<br />
As enterprises have come to depend more and more on technology to perform effectively, Enterprise IT organizations have matured, often due to the influence of IT consulting firms that make it their business to keep abreast of best practices.<br />
<br />
== EIT Concepts ==<br />
This knowledge area (KA) discusses enterprise IT, building upon the concepts elucidated in the IEEE/ACM ''[http://eitbokwiki.org EITBOK Guide to the Enterprise Information Technology Body of Knowledge]'' and general concepts of Systems Engineering elsewhere in SEBOK. <br />
An enterprise may be viewed from various perspectives: such as a system or a [[system of systems (SoS)|Enterprise Systems Engineering]]:<br />
* system-like enterprise: enterprises, like other systems, may have a tight coupling, single-executive function; <br />
* system of systems-like enterprise: may be a loosely coupled group of organizations with blurred boundaries and (yet) with (some) shared outcomes.<br />
The choice of perspective may vary with many factors: the enterprise itself, the mission or purpose, or the particular engineering task at hand. We can view an enterprise as a system with inputs and outputs in relation to the outside world, or a system of systems interacting through their individual inputs and outputs. <br />
An enterprise usually involves one (or more) organization(s) but need not be identified with the organization. As the scope of human and organizational participants of the enterprise widen, there may be no single point of control. For example, an ''extended enterprise'' could include a company, its suppliers and customers.<br />
Whatever perspective (system-like, SoS-like, other) is taken there are [[key ingredients|Enterprise Systems Engineering Background]] of any enterprise: capabilities, individual (competencies) and the organizational design. [[Capabilities|Enterprise Capability Management]] can be further categorized: “There are three different kinds of capability: organizational capability, system capability, and operational capability.” These capabilities determine what the enterprise is able to produce which may be external offerings or internal mechanisms. Operational capabilities create services and/or products which in turn produce value as determined by stakeholders. The capabilities of an enterprise are realized through [[Enterprise Systems Engineering Background|various enterprise elements]], including: “hardware, software, personnel, facilities, data, materials, techniques, and even services”. which include “soft” items, like people, processes, principles, policies, practices, organizations, doctrine, theories, and beliefs.<br />
EIT capabilities exist through lifecycles spanning from creation through eventual replacement and disposal. ''Life cycle models'' are schemes to aid in the understanding, design, planning and management of the capability of interest. <br />
“A life cycle for a system generally consists of a series of stages regulated by a set of management decisions which confirm that the system is mature enough to leave one stage and enter another.” Basic life cycle terms and concepts are discussed in [[System Lifecycle Approaches]]. Some typical life cycles are discussed in [[System Lifecycle Models]].<br />
A life cycle-based approach can be deployed across the several levels and used to manage evolution. These levels are:<br />
* the enterprise itself,<br />
* the processes and organizations constituting the enterprise,<br />
* the systems enabling the capabilities, services or products provided. <br />
It is important to distinguish between ''product'' and ''project'' lifecycle models. A product’s life cycle extends from its initial concept approval, through development and distribution, to its retirement. This is the cycle that is managed within an Enterprise IT organization, since EIT must manage the hardware or software product from its introduction, in the case of acquired capabilities, or from its concept approval and development, in the case of capabilities it builds, through its deployment, maintenance and eventual retirement (withdrawal). Each of these stages is usually managed as a project or a series of projects.<br />
However, most discussions of life cycles within software and systems discussions focus on ''project'' life cycles. See, for example, the ''Software Extension to PMBOK Guide'' (PMI 2013).<br />
==System of Systems Context in EIT==<br />
“Enterprise IT” (EIT) is used both to refer to the technology organization/business unit within the enterprise and to the enterprise’s information technology systems. In this article, we use EIT to refer to the technology systems. When referring to the organization, we use the phrase “Enterprise IT organization” or EIT organization. <br />
Enterprise IT organizations are responsible for complex socio-technical systems. Socio-technical systems in a business context (thus, EIT) contain technical elements (software, hardware, networks, storage, databases, etc.) but they also contain essential human components and necessary business processes. As covered in [[Introduction to Systems Engineering Fundamentals]], they exist in an engineered System Context that is a set of system component interrelationships within a real-world environment:<br />
This includes where problems come from and how they are defined, how we identify and select candidate solutions, how to balance technology and human elements in the wider solution context, how to manage the complex organizational systems needed to develop new solutions, and how developed solutions are used, sustained and disposed of. … Systems Engineering should consider the full Engineered System Context so that the necessary understanding can be reached and the right systems engineering decisions can be made. <br />
Socio-technical systems also have the following key characteristics: ''Openness'' in that they strongly interact with their environments, and ''unfinished'' in that they evolve over time.<br />
A complex of EIT systems is essential to the successful functioning of the humans in the enterprise. They rely on EIT’s technology for communication, for paying employees, for people management, for business measurement, and often for managing supply chains. Thus, “EIT needs to be viewed as a strategic partner to all the other functions and business units within an enterprise. This means that the results produced by EIT along with its effectiveness and efficiency are all critically important to the success of the enterprise.” [http://eitbokwiki.org/What_is_the_Enterprise_Perspective%3F]<br />
To accomplish this mission, the EIT organization builds and acquires new systems or system components, integrates them into the mega System of Systems, and maintains the integrity and interoperability of the individual components, but also the integrity of the entire complex of systems. In addition, security and performance levels must be achieved, benchmarked and maintained or improved.<br />
==Major concerns of the EIT Organization==<br />
The [http://eitbokwiki.org ''Enterprise IT Body of Knowledge''] provides a good deal of information about these major concerns, which we will not replicate here. Rather, links to the relevant areas are provided. The EITBOK demonstrates how, in providing technology systems and services to the enterprise, the EIT organization must skillfully manage such concerns as the following.<br />
<br />
===Enterprise Architecture===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Enterprise_Architecture Enterprise Architecture] for additional information. ''<br />
[http://eitbokwiki.org/Glossary#ea ''Enterprise architecture''] (EA) is the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. EA applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their organization's strategies. Enterprise architecture builds upon many of the concepts and practices of [[System Architecture Definition|systems architecture]] and also software architecture [https://www.sebokwiki.org/wiki/System_Architecture_Definition].<br />
This section will discuss Enterprise Architecture from the perspective of key [[Principles of Systems Thinking]], designated in this article with '''''bold italics'''''. There are many commonalities in architecture whether one is architecture systems, software or the enterprise [Unity]. In this article we highlight both commonalities and differences between Enterprise Architecture and Systems Architecture. <br />
Architecture takes place at the juncture of design problems and their solutions. Design problems rarely arrive fully formulated or “hatched” for the architect; much of the architecture effort is to analyze or formulate the problems to be solved. Often this involves negotiation both within the enterprise and with outside stakeholders. Possible solutions are limited by resources and schedule and therefore often must also be negotiated.<br />
A dominant principle of Enterprise Architecture is '''''separation of concerns''''' (SoC). This is due to the complexity of enterprises, with many forces acting upon them; the many technologies and disciplines involved in their creation and day-to-day operations; and due to the diversity of stakeholders involved in the enterprise (see [[EIT Roles]]). <br />
An application of SoC is the '''''boundary''''' principle which is crucial to separate what is “inside” the enterprise from what is “outside”. While the former is often under the enterprise’s control, the latter is often beyond its control. <br />
For some systems, determining the boundary is a key decision, subject to many possibilities and consequences. This is perhaps less the case for enterprises whose bounds are determined by the extent of organizations, regulations, supply chains or other criteria. Within an established boundary, the '''''holism''''' principle applies: to treat the enterprise as a unified whole, and, in particular, with respect to the '''''interaction''''' of the enterprise with its ''environment''—including stakeholders, other enterprises and systems. From an enterprise IT perspective, an enterprise is a ''system of systems. '' SoC offers a way to focus on the constituent systems in terms of their interconnections to one another to form the enterprise.<br />
Another useful application of SoC is to apply the principle of '''''multiple views''''' to depict the architecture of the enterprise in different ways to address the diverse interests (i.e., ''concerns'') of an enterprise’s various stakeholders. Each ''architecture view'' presents a specific perspective on the enterprise. To be understandable to its audiences (those various stakeholders), each view should follow the conventions of its ''architecture viewpoint'' (ISO/IEC/IEEE 42010 2011). Just as a map should have a legend, each view should have a documented viewpoint providing a prescribed set of conventions for looking at the enterprise through the resulting view. A viewpoint definition serves as a contract between the architect and stakeholders on ''how'' a selected set of concerns are to be addressed. Each viewpoint allows the architect to consider the enterprise in terms of various kinds of elements and relations among them and to present that view to those “concerned” stakeholders. Dominating concerns in enterprise architecture include interoperability, quality of systems and services, operations, managing change, and alignment with the enterprise’s mission, market, and technology. Via the principle of '''''dualism''''', we recognize that some viewpoints are paired, such as with process/data duality. Another pervasive duality in the enterprise is of people/technology in terms of what capabilities are automated and which are performed by people.<br />
In support of enterprise architecture, there are numerous ''enterprise architecture frameworks'' each providing a pre-defined, integrated set of viewpoints to frame typical, recurring concerns (ISO/IEC/IEEE 42010 Users Group 2022). The earliest recorded framework was (Hammer et al. 1986), developed in the mid-1980s in response to growing availability of distributed computing to the enterprise (Rivera 2013). In the late 1980s, US NIST created its Enterprise Architecture Model as a guide for US federal departments to organize their IT offerings (Fong and Goldfine 1989). NIST’s 5-layer model remains influential today. Despite never using the term “enterprise,” Zachman’s information systems architecture has had a major influence on how subsequent frameworks have been organized and depicted using grids or cubes. Later frameworks have evolved in response to emerging concepts, such as the move from client-server to service-oriented applications, as in the OASIS SOA Reference Model and its associated framework. The 1990s saw a proliferation of frameworks for defense enterprises including US DODAF, UK MODAF, NATO’s NAF and led to successors such as OMG’s UAF.<br />
Yet another application of '''''separation of concerns''''' is distinguishing today’s needs versus facilitating future needs; balancing '''''stability/change''''' and highlighting the temporal planning aspect of architecture of the enterprise. In concert with applying SOC, the architect uses the principle of '''''abstraction''''' to “forget” some details of the subject and thus focus on essentials. Just as SoC is a way of taking things apart, '''''abstraction''''' is a way of unifying or putting like things together through generalization. These two principles are perhaps the most central to architecture. SoC and abstraction work together: SoC picks out subjects and abstraction helps architects to focus upon the essentials of each subject. <br />
Returning to the '''''boundary''''' and '''''holism''''' principles, the enterprise architect applies these recursively. As architecting proceeds, the internal details of the enterprise become known in terms of '''''interaction''''' among its parts and other '''''relations'''''. Again, '''''multiple views''''' are used to factor specific '''''relations'''''into distinct views. Typical relations include Causality, Dependency, Client-Server, and Input-Output. <br />
There are a variety of ways to structure the enterprise based upon stakeholder needs, mission or charter, technologies or capabilities already in place. Among these are structuring principles including: <br />
* '''''Modularity''''' (separate and group capabilities into modules by commonalities); <br />
* '''''Network''''' (modules are linked together); <br />
* '''''Encapsulation''''' (separating architecture modules use from how they are implemented); <br />
* '''''Layer Hierarchy''''' (separation through gradual refinement); <br />
* ''''' Regularity''''' (uniformity of interactions, of structure within layer, within network). <br />
* ''''' Similarity/Difference''''' (recognizing the limits of Regularity)<br />
A simple pattern for architecture has been defined (Hofmeister ''et al. '' 2007). Its elements are Analysis, Synthesis and Evaluation. See Figure 1 below. <br />
''Architecture Analysis'' formulates architecturally-significant requirements (ASRs)—those requirements which influence an enterprise’s architecture. Architecture analysis is based on identified concerns and other information based on understanding the enterprise’s environment, known requirements, stakeholder needs and any constraints. ASRs reflect the “design problems” that the architecture must solve. In many cases, negotiations take place to modify incoming needs, requirements and expectations to make solutions possible. The result of this activity takes the form of ASRs, including architecture principles and initial enterprise-wide decisions.<br />
''Architecture Synthesis'' develops candidate solutions in response to the concerns and ASRs. During Synthesis the architect works out the details of solutions to the identified design problems, tradeoff and interactions between them which are likely to generate further design problems. Synthesis elaborates the ASRs, principles and initial decisions into more detailed solution elements. The principle of ''''' EQUIFINALITY''''' reminds us that for many stable situations (i.e., states of the enterprise), there are many ways to reach those states.<br />
''Architecture Evaluation'' validates whether chosen solutions satisfy ASRs or whether rework is needed (ISO/IEC/IEEE 42030 2019).<br />
Applying the principles discussed above is pervasive in enacting the Analysis–Synthesis–Evaluation pattern iteratively. <br />
<br />
<br />
Figure 1 A pattern for Architecture<br />
While there are many commonalities among EIT, systems and software architectures, Figure 2 addresses the relationships ''between'' them. Viewing an enterprise as a system, the EIT architecture governs the fundamental IT decisions of the enterprise. That enterprise might be extended to “outsiders” such as vendors, suppliers and perhaps customers. Depending upon the enterprise, the ''governs'' relationship may entail very strict rules or loose guidance. <br />
Within the enterprise, the ecosystem of systems, applications and data may be viewed as a system of systems. The EIT Architecture constrains the architectures governing individual systems, applications and data stores within the enterprise, so that these are able to interoperate and otherwise “play nicely” together.<br />
<br />
Figure 2 Relating Enterprise IT, Systems and Software Architecture<br />
===Strategy and Governance===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Strategy_and_Governance Strategy and Governance] for additional information. ''<br />
{{Blockquote<br />
|text= [http://eitbokwiki.org/Glossary#eit Enterprise information technology] (EIT) governance is the established process of defining the strategy for the EIT organization and overseeing its execution to achieve enterprise goals. Strategic planning translates the larger enterprise’s goals into EIT goals and defines what EIT must do to achieve those goals. This effort then communicates this hierarchy of goals: EIT goals as well as how they support the enterprise’s goals. EIT governance drives needed changes to achieve those goals, while maintaining agreed levels of operation. Taking into account various perspectives (such as financial, historical, environmental, and future projections), a strategic plan is a roadmap for action and change, both vertically and horizontally, across the EIT organization. The EIT organization’s strategic plans are based on the enterprise’s strategic plans, focusing on EIT’s role in them; EIT governance provides a monitoring and control framework to achieve strategic goals and objectives. Thus, EIT governance is essential for achieving the EIT strategy and goals..<br />
|author=[http://eitbokwiki.org/Strategy_and_Governance EITBOK wiki]<br />
}}<br />
<br />
The principle of ''''' PARSIMONY''''' applies here, too (see [[Principles of Systems Thinking]]). These principles will be designated in this article with '''''bold italics'''''. For example, the simplest possible measurement and reporting systems are most likely to be used and not corrupted. Similarly, the EIT organizational structure should be straightforward and easy to traverse so that staff can communicate and problem-solve in teams.<br />
In governing the EIT organization to meet its dual goals of satisfying its customers and meeting its budget and schedule commitments, EIT management encounters the difficulty of managing in the face of '''''dualism''''', “ensuring a constant dynamic balance often through a cyclic dominance of one element and then the other”. The most obvious instance of handling ''''' dualism''''' in EIT is the trade-off between budget, project prioritization and features within projects.<br />
===Change===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Change_Initiatives Change Initiatives] for more information. ''<br />
There are two levels of change management discussed in the EITBOK: organizational change management and changes to the IT organization’s assets, whether they be software, hardware, or telecommunications systems.<br />
In the larger sense, the introduction of new systems and services often also requires changes in people’s jobs and in the processes used to accomplish those jobs. Such efforts are intended to increase business value. Such changes require change initiatives because they involve guiding a mixture of stakeholders through the change process. This is one aspect of [http://eitbokwiki.org/Change_Initiatives change management].<br />
Change also occurs when existing systems or services must be updated to meet new needs. Depending on the scope of the proposed changes, a change initiative may be required in this situation, too. At any rate, a change request process must be initiated and tracked to disposition (deferral, rejection, or implementation). Changes also come about as a result of defect reports. In such cases, the defect report must be tracked throughout the report’s life cycle, to disposition (deferral, rejection, or implementation).<br />
These latter types of change management are discussed in detail in the EITBOK’s section on [http://eitbokwiki.org/Operations_and_Support Operations and Support].<br />
===Interoperability of Component Systems===<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Interoperability interoperability] for more information. ''<br />
As explained in the [http://eitbokwiki.org/Interoperability#One EITBOK], ''interoperability'' means “the ability of systems (including organizations) to exchange and use exchanged information without knowledge of the characteristics or inner workings of the collaborating systems (or organizations).” This definition is based on an ISO definition: “degree to which two or more systems, products, or components can exchange information and use the information that has been exchanged.” (ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models, 4.2.3.2. ) Note that this definition includes hardware components as well as software systems and the organizations in which they are used.<br />
Because technology changes so rapidly, and organizations themselves are frequently changing, achieving and maintaining interoperability is crucial. It is one of the main reasons that providing IT services is difficult and how it differs from engineering and delivering finished products, whether off-the-shelf products or bespoke systems.<br />
===Security of Systems and Data===<br />
{{Blockquote<br />
|text=There are only two types of companies: those that have been hacked, and those that will be.<br />
<br />
|author= FBI Director Robert Mueller, October 2012<br />
}}<br />
{{Blockquote<br />
|text= There are two kinds of big companies in the United States. There are those who've been hacked by the Chinese and those who don't know that they've been hacked by the Chinese.Quoted material.<br />
|author=FBI Director James Comey, October 2014<br />
}}<br />
''See the EITBOK’s section on [http://eitbokwiki.org/Security security] for additional information. ''<br />
While there are many definitions for security, most include the three dimensions of confidentiality, integrity, and availability (sometimes referred to as the [http://eitbokwiki.org/Glossary#ciatriad CIA triad]). As such, the primary goal of EIT security is to preserve the confidentiality, integrity, and availability of information and information systems. <br />
The principles behind an organization’s [http://eitbokwiki.org/Glossary#isms information security management system] (ISMS) should be to design, implement, and maintain a coherent set of policies, processes, and systems that keep the risks associated with its information assets at a tolerable level, and yet, manage the cost and inconvenience of said risk management. As such, the goals of EIT security are to:<br />
* Always understand the current risk tolerance of the enterprise with respect to information and device security.<br />
* Understand the security threats and potential damages to information, devices, and individuals.<br />
* Create and follow policies and procedures that keep cyberattack risk and damages at or below a tolerable level.<br />
* Effectively and efficiently detect and deal with<br />
[http://eitbokwiki.org/Security#One cyberattack incidents].<br />
Ensuring security in EIT has been made even more pressing and more difficult by the proliferation of mobile devices in enterprises and their ever-increasing use to conduct business. Increasingly, personal devices (Bring Your Own Device – BYOD) are used, accessing both corporate networks and public networks. The cost of [https://www.checkpoint.com/downloads/products/check-point-mobile-security-survey-report2013.pdf mobile security incidents] very easily can outweigh the cost of the mobile device itself. <br />
==Quality of Systems and Services==<br />
The Enterprise ''Information'' Technology organization has, since its origins, had as its primary responsibility the timely provision of information to the larger organization. The information is expected to be not only timely, but also accurate and relevant. While the EIT organization itself may not be responsible for creating the data, it is responsible for the physical and logical validity and [https://simplicable.com/new/data-integrity-vs-data-quality integrity of the data] that is used to construct information. It is for this reason that defining and using appropriate processes is essential to ensure high-quality operation, including the development or acquisition, implementation and integration of new or changed capabilities.<br />
The EITBoK details the quality concepts of<br />
* How to approach measuring [http://eitbokwiki.org/Quality#Measuring_Quality Quality]<br />
* The importance of Quality in [http://eitbokwiki.org/Quality#Requirements_Management Requirements Management]<br />
* Understanding an organization’s [http://eitbokwiki.org/Quality#Quality_Capability Quality Capability]<br />
* The differences between [http://eitbokwiki.org/Quality#QMS_and_QC_vs._QA QMS, QC and QA]<br />
* Cost of Quality in [http://eitbokwiki.org/Quality#Technical_Debt_and_the_Cost_of_Rework Technical Debt and the Cost of Rework]<br />
==Disaster Preparedness==<br />
<br />
As explained in the [http://eitbokwiki.org/Disaster_Preparedness EITBOK], disaster preparedness and [http://eitbokwiki.org/Glossary#dr disaster recovery] (DR) support business-continuity planning and include planning for EIT resiliency, as well as recovery from adversity, so that critical business services affected are restored to a satisfactory working state within an [http://eitbokwiki.org/Glossary#acceptable acceptable] timeframe after an event.<br />
The EITBoK devotes a chapter to how the EIT organization and its parent must plan in advance for how it will provide sufficient organizational resilience to recover from disasters and return to normal operation as rapidly as possible.<br />
It provides the following examples of disasters and service interruptions that could occur and should be considered in prevention and recovery planning:<br />
These are examples of disasters:<br />
* Natural disaster affecting datacenters or EIT service operations (flood, fire, earthquake, wind)<br />
* Security breach resulting in a disaster (destruction of data, admin password changes, virus/malware installation, sabotage)<br />
* Usage error (accidental deletion, unplug/turn off system resulting in corruption)<br />
* Utility failure affecting datacenters (loss of power even after UPS)<br />
* Vendor failure (cloud provider security failure, oil spill)<br />
* Staffing issue (employment dispute/walkout, epidemic)<br />
These are examples of unpreparedness:<br />
* Requiring use of computers or printers when power is out<br />
* Requiring use of Internet when power or connectivity is out<br />
* Single point of knowledge/control for administration access<br />
* Lack of offsite backup storage<br />
* Lack of working restoration from backups<br />
* Lack of failover datacenters in separate locations<br />
* Undocumented or out-of-date documentation for system interfaces<br />
*Requiring use of phones that are out of power<br />
* Lack of designation of leaders in restoration efforts (who is in charge of restoring service and they know they are in charge)<br />
* In general, no cohesive, comprehensive EIT service restoration plan<br />
==Operations and Support of Delivered Systems and Services==<br />
[http://eitbokwiki.org/Operations_and_Support Operations and support activities] focus on maintaining an operation normal state in EIT environments, meaning that systems and processes execute according to expectations, with no surprises to users. This desired normal state requires the careful management of EIT assets and services via Operations, as well as of users via Support.<br />
Normal states can be disrupted either by the expected and planned transition of an asset, or by an unexpected event, be it as large as a disaster or by the discovery of a system defect. In the former case, the Disaster Recovery Plan is executed; in the latter, incident management kicks in when a system halts, or problem management is exercised when an operational system is not functioning as expected. The processes needed to ensure effective application of these complex functions is detailed in the [http://eitbokwiki.org/Operations_and_Support#Guiding_Principles Operations and Support Knowledge Area] within the EITBOK. <br />
ISO/IEC/IEEE 20000 may be used by any organization to develop and manage EIT operations, along with the current version of [https://www.servicenow.com ITIL].<br />
ITIL for many is the tool of choice for the operations and infrastructure side of IT, particularly for IT services. <br />
==Ethics==<br />
See the EITBOK’s section on [http://eitbokwiki.org/Ethics ethics] for additional information.<br />
Both the IEEE and ACM require their members to adhere to Codes of Ethics. See the [https://www.ieee.org/about/corporate/governance/p7-8.html IEEE Code of Ethics] and [https://www.acm.org/code-of-ethics ACM Code of Ethics and Professional Conduct]. Both of these can be downloaded freely. In addition, the IEEE Computer Society and the ACM worked together on the [https://dl.acm.org/action/downloadSupplement?doi=10.1145%2F265684.265699&file=acm-se-code-of-ethics.html Software Engineering Code of Ethics] (also available [https://dl.acm.org/doi/10.1145/265684.265699 here]).<br />
The organization should create an easily accessible Code of Ethics:<br />
* Ethical assertions should be documented and socialized in EIT in the form of a Code of Ethics, tied to the overall business code of ethics, and signed off by all staff so that violations can be cause for reprimand or dismissal.<br />
* Vendors should be held to similar ethical standards.<br />
* Lists of employees who have signed off on the Code of Ethics are maintained by EIT governance.<br />
The EITBOK has identified EIT ethical topics that include:<br />
* Those actions and decisions that may be illegal<br />
* Consideration of the social impact of the work at hand—if it will cause harm<br />
* Alignment of business and EIT strategies and policies to an ethical standard<br />
* Incorporation of the ideals of professionalism<br />
* Adherence to applicable regulatory intent<br />
* Protection for whistle blowers<br />
Areas to specifically highlight:<br />
* Activities that interfere with or corrupt the proper function of computers, applications and systems<br />
* Activities that interfere with digital privacy or intellectual rights of others<br />
* Respect for confidentiality, privacy, permissions, and access rights<br />
* Inappropriate bias (skewing) of analysis and reporting<br />
* Inaction in the face of likely ethics violations<br />
==EIT Roles==<br />
Several roles play a part in accomplishing the EIT organization’s mission. Just as a systems engineer can play several roles in a given project, so might several people in an EIT project combine to fulfill the systems engineering function. <br />
The function of EIT systems engineering is to orchestrate systems development, delivery and operation such that the larger organization achieves favorable outcomes in complex environments. Unlike systems projects that are built for known problems, EIT systems may change in unpredictable ways. A primary concern focuses on how quickly systems adapt to change. This entails a type of resiliency based on skills in establishing options and alternative solutions as well as strategies tailored to the volatility of changing needs and available technologies. It also requires expertise in assuring that systems quality is assured from the start.<br />
Different countries, geographic areas and organizations do not always use the same terminology to reference the functions that the roles contributing to systems engineering perform. The following section will provide information about some major international models for defining EIT skills and capabilities. Generally, though, the necessary roles across the product life cycle include these:<br />
* Business Sponsor/Champion<br />
* Enterprise Architect<br />
* Systems Engineer<br />
* Financial Manager<br />
* Application Architect<br />
* Business Analyst and/or Process Analyst<br />
* Data Analyst and/or Data Architect<br />
* Software Engineer and/or Programmer<br />
* Quality Assurance & Testing<br />
* Network Engineer<br />
* Telecoms Engineer<br />
* Integration Expert <br />
* Transition to Operations Manager<br />
* Release Manager<br />
* Availability Manager<br />
* Capacity Manager<br />
* Change Manager<br />
* Configuration Manager<br />
* EIT Operations Manager<br />
* Incident Management<br />
* Problem Manager<br />
* Service Level Manager<br />
* Database Administrator<br />
* Network Manager<br />
* Product Manager<br />
System engineering activities orchestrate the work of these roles so that they function together, rather than in silos or at cross purposes.<br />
==Examples of Systems Engineering in EIT==<br />
Systems Engineering provides a holistic discipline for integrating and managing the contributions of all roles needed to establish and provide EIT products and services. It ensures that a single perspective does not dominate outcomes; instead, it seeks balance among the many disciplines represented above in creating a consistent product or service that meets the interests and needs of enterprise users (and, perhaps, partners). It boils down to common sense, technical sense, knowing when to ask the right questions, and getting the data to support the answers to those questions. System Engineering achieves this via Systems Engineers. In many instances, though, the SE function is accomplished through Project Management approaches using Integrated Product Teams that include technical experts. Thus, although not specifically calling out a Systems Engineering function, the use of IPTs involved the use of SE practices.<br />
A doctoral dissertation from Purdue University performed a survey and causal analysis of project failures and of accidents(Aloisio, 2018). The results were similar to those found in reviews of IBM consulting projects in the 1990s . The following are examples of Systems Engineering interventions that prevented project failures. Almost all point to the lack of the System Engineering balancing act needed for product delivery.<br />
* A widely used document processing product was undergoing a major upgrade. The new VP of Engineering wanted a project review before committing to a schedule. The review showed that the proposed schedule only considered the development effort and did not give sufficient weight to the voices of the testing and documentation organizations, while the needs of the tech support group had been completely overlooked. By establishing an integrated product management team that included technical expertise, as well as expertise in work breakdown and estimating, a realistic effort was defined and the resulting 9-month schedule was met within 3 weeks.<br />
* A Silicon Valley start-up was depending entirely on an offshore development effort to produce its first product. All senior management was in the U.S. The VP of engineering made monthly visits to the development team. The CEO began to feel uneasy about the team’s ability to deliver on schedule sensing that a lot of finger pointing within the development team itself signaled problems. There was no SE or IPT guiding the project. The VP of Engineering seemed unable to sort things out. A project review showed that the probable delivery date was at least 6 months beyond what the CEO was being told. The project was shut down.<br />
* A major player in Human Resource Management had made commitments to deliver a new product. The project involved more than 100 people across the U.S. The delivery date kept slipping. Project roll-out would involve both installation of software and hardware at client sites, as well as installation and staff training at the large, centrally located Client Services organization. Executive Management needed to decide whether to reorganize this very expensive effort or cancel it. Again, the successful solution depended on establishing an effective cross-functional team (IPT) that necessarily included representatives from the technical teams. The IPT was supported by a newly established Project Management Office (PMO). The PMO integrated the geographically disparate efforts by establishing communication channels, as well as common estimating and scheduling practices. The PMO also instituted monthly critical metrics reports to show the IPT bottlenecks and inefficiencies across the project, from development efforts to Client Services set-up to Payroll technical support.<br />
There are far more examples of the lack of systems engineering practices in EIT projects than in their successful use (unfortunately, this seems also to be true in lots of software projects outside of EIT). Systems Engineering provides a holistic discipline for integrating and managing the contributions of all of the roles needed to provide EIT products and services. It ensures that a single perspective does not dominate outcomes.<br />
==Key External Models of EIT Organizational Capability and Maturity==<br />
Because EIT is critical to businesses globally, considerable effort has gone into establishing universal frameworks for EIT skills, along with definitions of levels of capability of each skill. In addition, at least 2 models have been developed for evaluating the organizational performance of EIT. The effectiveness of systems engineering is key to the effectiveness of the EIT organization.<br />
===IT-CMF: IT-Capability Maturity Framework=== <br />
The IT-CMF had its origin in a quality improvement effort at Intel Labs Europe in Ireland. Its intent, as described at the <br />
[https://cio-wiki.org/wiki/IT_Capability_Maturity_Framework_(IT-CMF) CIO Index website] was to quantify and demonstrate the true value impact of IT. IT-CMF is used to measure, develop, and monitor an organization’s EIT capability maturity. It consists of 35 EIT management capabilities organized into four macro capabilities: managing EIT like a business; managing the EIT budget; managing the EIT capability; and managing EIT for business value. Its 35 critical capabilities (CCs) are [http://eitbokwiki.org/Enterprise_IT_Maturity_Assessment described] as “A defined EIT management domain that helps mobilize and deploy EIT-based resources to effect a desired end, often in combination with other resources and capabilities”. <br />
===CMMI: Capability Maturity Model Integration (US)===<br />
The CMMI had its origin in 1987 in a model requested by the U.S. Department of Defense for determining the capability maturity of contractor software development organizations. This became the Capability Maturity Model (CMM). Since then, it has been expanded into a set of Capability Maturity Models, all based on five levels of demonstrably increasing maturity as measured by organization performance. That set was then integrated and became the CMMI. The CMMI set addresses [https://cmmiinstitute.com/dev Development], [https://cmmiinstitute.com/svc Services], [https://cmmiinstitute.com/sm Supplier Management], [https://cmmiinstitute.com/pm People Management], and [https://cmmiinstitute.com/dm Data Management].<br />
===SFIA: Skills Framework for the information Age (Europe, Canada and US)===<br />
The SFIA Framework has been downloaded and used by organizations and individuals in nearly 180 countries. It can be downloaded for free at [https://www.sfia-online.org]. It identifies 97 professional skills across EIT and supporting areas with seven levels of responsibility, which provide generic levels of responsibility, taking into account reflect experience and competency. These describe the behaviors, values, knowledge, and characteristics that an individual should have in order to be considered competent at a particular level.<br />
===E-CF: European Competency Framework (EU)===<br />
The ECF was the first sector-specific implementation of the European Qualifications Framework (EQF). The European Norm (EN) 16234-1 European e-Competence Framework (e-CF) provides a reference of 41 competences as applied at the Information and Communication Technology (ICT) workplace, using a common European reference for competences, skills, knowledge and proficiency levels. The E-CF Explorer web tool is available [https://ecfexplorer.itprofessionalism.org/ online].<br />
===I Competency Dictionary: EIT skills as Defined by METI/ IPA (Japan)===<br />
The Japanese government’s Information-Technology Promotion Agency (IPA), established by the Ministry of Economy, Trade and Industry (METI) developed the ”I Competency Dictionary” (iCD) to support the IT Engineers Examination. It underlies the METI/IPA Skills Standards for IT Professionals, abbreviated as ITSS, established in 2002. ITSS organizes skills within the information services industry into 11 job categories and 35 specialty fields. In each field, there are seven levels of competence based on individual experience and ability to perform. One appealing feature of ITSS is that this standard allows engineers to draw roadmaps for their own futures and career advancement (Career Path). Approximately 90% of large enterprises and over 60% of SMEs in Japan have introduced or are considering using ITSS. Information in English is available at https://www.ipa.go.jp/english/humandev/forth.html.<br />
===ITIL: Information Technology Infrastructure Library===<br />
According to ITLIlibrary.org, the ITIL Open Guide website, “The Information Technology Infrastructure Library (ITIL) defines the organisational structure and skill requirements of an information technology organisation and a set of standard operational management procedures and practices to allow the organisation to manage an IT operation and associated infrastructure. … The [https://www.itlibrary.org/ “library”] itself continues to evolve. This comprises five distinct areas: <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Strategy ITIL Service Strategy]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Design ITIL Service Design]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Transition ITIL Service Transition]; <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Service_Operation ITIL Service Operation]; and <br />
* [https://www.itlibrary.org/index.php?page=ITIL_Continual_Service_Improvement ITIL Continual Service Improvement].”<br />
It originally grew out of a British government sponsored effort to regularize IT Service Management (ITSM). <br />
==References==<br />
===Works Cited===<br />
Fong, E.N. and A.H. Goldfine. 1989. ''Information Management Directions: The Integration Challenge. '' National Institute of Standards and Technology (NIST) Special Publication 500-167, September 1989. https://csrc.nist.rip/library/NIST%20SP%20500-167.pdf <br />
Hammer, M., T.H. Davenport and J. Champy. 1986. ''Dispersion and Interconnection: Approaches to Distributed Systems Architecture'', Cambridge, MA: CSC Index Inc. and Hammer and Company, Inc. (June 1986). Available as: https://www.globalaea.org/general/custom.asp?page=Resources <br />
Hilliard, R. 2015. “Lessons from the fundamental unity of architecting”. ''Software Engineering in the Systems Context'', editors: Ivar Jacobson and Harold 'Bud' Lawson.<br />
Hofmeister, C. et al. 2007. “A general model of software architecture design derived from five industrial approaches”. ''The Journal of Systems and Software'' 80(1). <br />
ISO/IEC 25010:2011 ''Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models'', 4.2.3.2.<br />
ISO/IEC/IEEE 42010 Users Group. ''Survey of Architecture Frameworks'' Available as: http://www.iso-architecture.org/42010/afs/<br />
ISO/IEC/IEEE. 2011. ISO/IEC/IEEE 42010:2011, ''Systems and software engineering — Architecture description. ''<br />
PMI. 2013. ''Software Extension to PMBOK® Guide – Fifth Edition. '' Newtown Square, PA, USA: Project Management Institute (PMI). Available as: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/software-extension-5th-edition.<br />
Rivera, R. 2013. “The PRISM Architecture Framework – Was it the Very First Enterprise Architecture Framework?” ''Journal of Enterprise Architecture'', November 2013<br />
Zachman, J. 1987. “A Framework for Information Systems Architecture”. ''IBM Systems Journal'', pp454-470, 1987 <br />
==Primary References==<br />
IEEE Computer Society. ''Enterprise IT Body of Knowledge''. Available: http://eitbokwiki.org<br />
==Additional References==<br />
IT Capability Maturity Framework (IT-CMF): The Body of Knowledge Guide. 2015. Editors. Martin Curley, Jim Kenneally, Marian Carcary. Van Haren Publishing.<br />
Lessons from Systems Engineering Failures: Determining Why Systems Fail, The State of Systems Engineering Education, and Building an Evidence-Based Network to Help Systems Engineers Identify and Fix Problems on Complex Projects, Diane Constance Aloisio, December 2018.<br />
==International Standards Guiding EIT==<br />
ANSI/AIAA. 2012. ''ANSI/AIAA Guide to the Preparation of Operational Concept Documents. '' ANSI/AIAA G-043A-2012e.<br />
IEEE 2012 Std 828™-2012, ''IEEE Standard for Configuration Management in Systems and Software Engineering. ''<br />
ISO 10004:2012, Quality management—Customer satisfaction—Guidelines for monitoring and measuring<br />
ISO 10007:2003, Quality management systems—Guidelines for configuration management<br />
ISO 18238:2015, Space systems—Closed loop problem solving management<br />
ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models<br />
ISO/IEC 16350:2015, Information technology—Systems and software engineering—Application management<br />
ISO/IEC 19770-1:2012, Information technology—Software asset management—Part 1: Processes and tiered assessment of conformance<br />
ISO/IEC 20000-1:2011, (IEEE Std 20000-1:2013) Information technology—Service management—Part 1: Service management system requirements<br />
ISO/IEC 20000–2:2012, Information technology—Service management—Part 2: Guidance on the application of service management systems<br />
ISO/IEC TR 20000–10:2015, Information technology—Service management—Part 10: Concepts and terminology<br />
ISO/IEC TR 20000–11:2015, Information technology—Service management—Part 11: Guidance on the relationship between ISO/IEC 20000-1:2011 and related frameworks: ITIL®<br />
ISO/IEC TR 20000-12—Information technology—IT Service management—Part 12: Guidance on the relationship between ISO/IEC 20000-1:2011 and service management frameworks: CMMI-SVC®<br />
ISO/IEC/IEEE 14764-2006, Software Engineering—Software Lifecycle Processes—Maintenance<br />
ISO/IEC 15939:2007, Systems and software engineering—Measurement process<br />
ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description <br />
<br />
<br />
----<br />
<center>[[ Systems Engineering and Economics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Quality Attributes|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=A_Framework_for_Viewing_Quality_Attributes_from_the_Lens_of_Loss&diff=65904
A Framework for Viewing Quality Attributes from the Lens of Loss
2022-10-10T03:58:08Z
<p>Mhaas: table formatting</p>
<hr />
<div>----<br />
'''''Lead Author:''''' ''John S. Brtis''<br />
----<br />
<br />
Important but often under-considered areas of systems engineering address potential losses associated with the development and use of systems. These areas fall under the rubric of Loss-Driven Systems Engineering (LDSE), the value-adding unification of the systems engineering specialty areas that address the potential losses associated with systems.<br />
<br />
==Overview== <br />
Systems engineering methodologies often focus on the delivery of desired capability. Methodology sources such as the Systems Engineering Handbook (Walden 2015) and ISO/IEC/IEEE 15288 (ISO) provide full lifecycle and fully integrated methodologies that focus on the generation and deployment of a systems to deliver capabilities. Those methodologies are largely capability-driven, and do not provide detailed fully integrated attention to potential loss. Loss and loss-driven specialty areas are largely treated in isolation.<br />
Examples of loss-driven specialty areas include resilience, safety, security, operational risk, environmental protection, quality, and availability. <br />
There is commonality and synergy among these specialty areas, which should be addressed by systems engineering. <br />
Potential synergies include:<br />
* Shared loss scenarios<br />
* Shared requirements<br />
* Shared modeling and analysis techniques<br />
* Shared architecture and design solutions<br />
* Shared risk management<br />
<br />
The expected benefits of applying a unified loss-driven viewpoint in the systems engineering processes include:<br />
* Reducing engineering effort by eliminating redundant efforts among the specialty areas<br />
* Helping to ensure a comprehensive consideration of loss<br />
* Ensuring cohesion and elimination of conflicts among the loss-driven solutions<br />
* Identifying highly effective solutions that address the interests of multiple loss-driven specialty areas<br />
* Providing a holistic viewpoint addressing the multiple perspectives<br />
* Reducing the load of data generated by multiple specialty areas to a minimal, non-redundant set<br />
* Mutual learning among the loss-driven specialty areas <br />
<br />
===Background and Origins===<br />
Engineers at the MITRE Corporation explored the commonality of “protecting against loss” in the areas of security, safety, and resilience as part of an effort to improve a sponsor’s systems engineering methodologies (Brtis 2020). In parallel, these engineers raised and explored the issue with the INCOSE resilience and security working groups. This led to the realization that these specialty areas had commonalities, and synergies with many of the systems engineering specialty areas. The term “loss-driven systems engineering” was coined to identify this area of common interest. <br />
These concepts were discussed with the INCOSE TechOps Director at IS17, and he recommended that the concept be pursued as an INCOSE initiative. An exploratory meeting on LDSE was held at INCOSE IW18. At that meeting participants agreed that this concept should be pursued and decided that as a first step, a special theme issue, on loss-driven systems engineering, of INCOSE ''Insight'' magazine should be pursued, to be followed by a section in the INCOSE SEBOK. That issue of ''Insight'' was published in December 2021.<br />
===The Basis of Commonality===<br />
Systems engineering must address all loss-driven specialty areas in a mutually supportive and optimized manner. The exact definitions and demarcation between the different specialty areas are moot. What matters is meeting all the objectives of the loss-driven areas.<br />
Loss-driven areas often have common objectives, common concepts and principles, common requirements, common architectural solutions, common design solutions, common analyses, and common methodologies. Engineers responsible for loss-driven areas can often do a better job if they work collaboratively. This is because they are all interested in the same overarching concern: addressing potential losses associated with the system of interest. <br />
An inspection of the Systems Engineering Handbook (Walden 2015) identified specialty engineering areas that shared the concerns of loss-driven systems engineering. Those identified include: <br />
* availability<br />
* environmental impact <br />
* maintainability<br />
* resilience engineering<br />
* reliability<br />
* risk management<br />
* system safety engineering<br />
* system security engineering<br />
* quality management<br />
<br />
==Attributes Shared by the Loss-Driven Specialty Areas, a Potential for Unification==<br />
<br />
The loss-driven specialty areas share attributes that specify the scope of each specialty area. All the loss-driven specialty areas have as attributes: <br />
* the types of assets considered<br />
* the types of loss addressed<br />
* the types of adversity addressed <br />
* the coping strategies considered<br />
* the aspects of the system and its environment under consideration <br />
These attributes define the scope of each specialty area. These scopes differ among the loss-driven specialty areas, but in many cases, they overlap. These loss-driven attributes and the possibility of aggregating their overall values, provide a basis for integrating the loss-driven specialty areas, by aggregating the range of values of the parameters and then by addressing their aggregate scopes. Brtis (2020) considers each of these attributes. Figure 1 provides an aggregate summary of the scope of considerations identified for loss-driven attributes. <br />
Properly engineering a system, requires consideration of the full range of each of the loss-driven attributes.<br />
[[File:Loss Driven Systems Engineering Figure 1.png|thumb|center|800px|<center>'''Figure 1: Attributes and Scope of the Integrated Loss-Driven Systems Engineering Problem Space'''</center>]]<br />
<br />
==Core Principles for LDSE==<br />
Winstead (2020) investigated the commonality among principles being articulated for individual loss-driven specialty areas. He identified fundamental principles that can be unified across the specialties. <br />
* Candidate principle 1: Systems engineering minimizes hazards.<br />
* Candidate principle 2: Systems engineering seeks to control hazards that cannot be avoided, including assuring transitions from one known acceptable mode or state to another known and acceptable one.<br />
* Candidate principle 3: Systems engineering uses proven and accepted processes, solutions, methods, materials, etc. when the process, etc. achieves the intended trustworthiness.<br />
* Candidate principle 4: The human within the system should be enabled to prevent, minimize, and recover from loss when possible.<br />
* Candidate principle 5: Systems engineering should strive for the simplest solutions<br />
* Candidate principle 6: Systems engineering produces evolvable systems likely to maintain or improve on loss-driven properties through change.<br />
* Candidate principle 7: Actions should trace to the entity responsible. <br />
* Candidate principle 8: Any critical task should be possible to perform in more than one way.<br />
Winstead (2020) also considered the systems engineering principles of Watson (2019) and discusses minimal changes needed to make them well-suited for application to loss-driven systems engineering. <br />
<br />
==LDSE in the SE Activities==<br />
Brtis (2020) found that several the SE practices identified in ISO 15288 and the INCOSE SE Handbook need to be augmented to adequately address the needs of LDSE and recommended specific additions for the following practice areas. <br />
*Business or Mission Analysis Process<br />
*Stakeholder Needs and Requirements Definition Process<br />
*System Requirements Definition Process<br />
*Architecture Definition Process<br />
*Design Definition Process<br />
*Risk Management Process <br />
<br />
==LDSE Design Techniques==<br />
Winstead (2021) investigates what he calls “loss control” for cyber-physical systems. He investigates loss control independent of any particular systems engineering specialty area. He recommends a set of loss control design principles.<br />
<br />
*'''''Anomaly Detection''''' - Any salient anomaly in the system or in its environment is detected in a timely manner that enables effective response action. <br />
*'''''Commensurate Protection''''' - The strength and type of protection provided to an element must be commensurate with the most significant adverse effect that results from a failure of that element. <br />
*'''''Commensurate Response''''' - The design should match the aggressiveness of an engineered response action’s effect to the needed immediacy to control the effects of each loss scenario. <br />
*'''''Continuous Protection''''' - The protection provided for an element must be effective and uninterrupted during the time that the protection is required. <br />
*'''''Defense-in-depth''''' - Loss is prevented or minimized by employing multiple coordinated techniques and strategies. <br />
*'''''Distributed Privilege''''' - Multiple authorized entities must act in a coordinated manner before an operation on the system is allowed to occur. <br />
*'''''Diversity (Dynamicity) ''''' - The design delivers the required capability through structural, behavioral, data, or control flow variation. <br />
*'''''Domain Separation''''' - Domains with distinctly different protection needs should be physically or logically separated. <br />
*'''''Least Functionality''''' - Each element should have the capability to accomplish its required functions, but no more. <br />
*'''''Least Persistence''''' - System elements and other resources should be available, accessible, and able to fulfill their design intent only for the time they are needed. <br />
*'''''Least Privilege''''' - Each element should be allocated privileges that are necessary to accomplish its specified functions, but no more. <br />
*'''''Least Sharing''''' - System resources should be shared among system elements only when necessary, and among as few system elements as possible. <br />
*'''''Loss Margins''''' - The system is designed to operate in a state space sufficiently distanced below the threshold at which loss occurs. <br />
*'''''Mediated Access''''' - All access to and operations on system elements are mediated. <br />
*'''''Protective Defaults''''' - The default configuration of the system provides maximum protection effectiveness. <br />
*'''''Protective Failure''''' - A failure of a system element should neither result in an unacceptable loss, nor invoke another loss scenario. <br />
*'''''Protective Recovery''''' - The recovery of a system element should not result in, nor lead to, unacceptable loss. <br />
*'''''Redundancy''''' - The design delivers the required capability by the replication of functions or elements. <br />
<br />
==Technical Management Considerations==<br />
The effective coordination and management of LDSE specialty areas – areas that have often operated independently and in isolation of one another -- poses a challenge. <br />
Jackson (2020) discusses the concept of siloism in the context of LDSE projects and ways to mitigate that effect. Siloism is the unwillingness of members of any team to share information. Failure to mitigate siloism can reduce the effectiveness of the entire team. Jackson recommends mitigating siloism using integrated product teams (IPT), which utilize organizational structure and rigorous management to encourage sharing of information among specialties. <br />
Brtis (2021) suggests that for LDSE the systems engineer should holistically consider:<br />
*the full spectrum of adversities<br />
*the full spectrum of weaknesses, defects, flaws, exposures, hazards, and vulnerabilities<br />
*the full spectrum of assets and losses<br />
*the full spectrum of timeframes of interest<br />
*the full spectrum of coping mechanisms<br />
<br />
and further, suggests the systems engineer:<br />
*elicit, analyze, and capture loss-driven requirements as part of the overall stakeholder and system requirements development. <br />
*make the loss-driven architectural decisions holistically across the loss-driven specialty areas<br />
*make the loss-driven design decisions holistically across the loss-driven specialty areas<br />
*integrate the management of risks associated with all loss-driven areas<br />
<br />
Endler (2021) considers real life integration of loss-driven systems engineering activities into system development activities. Challenges identified include lack of appreciation of the importance of loss-driven systems engineering activities and organizational barriers. He finds that existing systems engineering standards poorly describe loss-driven systems engineering activities and fail to integrate loss-drive activities with traditional engineering activities. He proposes methods to overcome those barriers based on widely accepted standards. He offers an approach to accomplish the needed integration with emphasis on the need that loss-driven systems engineers participate throughout the system life cycle and be supported by a common understanding of an integrated approach.<br />
<br />
==Consequences for Model-Based Systems Engineering==<br />
Model-based systems engineering data and models need to be augmented to address the shared attributes of loss-driven systems engineering: assets, losses, adversities, and coping techniques and the common information artifacts identified above. Table 1 identifies some of the additional modeling information (in SysML form) that needs to be captured during the various lifecycle stages to support the effective development and documentation of loss management scenarios and loss management requirements. <br />
<br />
{|align ="center"<br />
|+'''Table 1. Modeling Information and Artifacts During Lifecycle Phases (Brtis 2020).'''<br />
!Lifecycle Phase<br />
!Artifacts and Information<br />
|-<br />
|Mission and Stakeholder Needs Analysis<br />
|*Add adversities to the context diagram as actors<br />
*Add loss management scenarios as use cases<br />
|-<br />
| Stakeholder <br />
Requirements<br />
|*Develop use case interaction diagrams to document the interaction of actors and architectural modules during the loss management scenarios<br />
*Develop sequence diagrams to represent the activity flow during loss management scenarios<br />
|-<br />
|System Requirements<br />
|*Develop activity diagrams to show the states of the system (and adversities) during loss management scenarios<br />
|-<br />
|Architecture and System Design<br />
|*Develop state models of the loss management scenarios<br />
*Model events and signals among the architectural nodes<br />
|-<br />
|System Design<br />
|*Propose and select loss management design features<br />
*Document loss management related object distribution<br />
|}<br />
<br />
==Use Case: Manned Space Rescue Vehicle==<br />
Cureton (2020) explores the applicability of LDSE to a use case, a hypothetical manned space rescue vehicle, via a thought experiment regarding desirable characteristics for achieving resilience, safety, reliability, security, and other loss-driven goals. Various design reference missions are explored for assessment of required loss-driven capabilities in automated flight operations for a hypothetical manned space rescue vehicle.<br />
<br />
==Summary==<br />
Loss-driven systems engineering offers a valuable unification of loss-driven systems engineering specialty areas. Applying this can integrate currently isolated systems engineering activities, leading to improved system effectiveness, and reduced systems engineering costs, while improving the management of potential losses associated with the development and use of systems.<br />
<br />
==References==<br />
===Works Cited===<br />
Cureton, K. L. 2020. “Role of LDSE for a Hypothetical Manned Space Rescue Vehicle.” ''INCOSE INSIGHT,'' December 19-21.<br />
<br />
Brtis, J. S. and M. A. McEvilley. 2019. “Systems Engineering for Resilience,” MITRE Technical Document #190495, The MITRE Corporation. Available: https://www.mitre.org/publications/technical-papers<br />
<br />
Endler, D. 2020. “Integrating Loss-Driven Systems Engineering Activities.” ''INCOSE INSIGHT'', December 14-18.<br />
<br />
ISO (International Organization for Standardization. 2015. ISO/IEC/IEEE 15288:2015. Systems and software engineering – System life cycle processes. Geneva, CH: ISO.<br />
<br />
Jackson, S. 2020. “Loss-Driven Systems Engineering and Siloism.” ''INCOSE INSIGHT,'' December 32-33.<br />
<br />
Watson, Michael D. 2019. "Systems Engineering Principles and Hypotheses." ''INCOSE INSIGHT,'' May 18-28.<br />
<br />
Winstead, M., D. Hild, M. McEvilley, 2021. “Principles of Trustworthy Design of Cyber-Physical Systems.” MITRE Techinical Report #210263, The MITRE Corporation, June 2021. Available: https://www.mitre.org/publications/technical-papers<br />
<br />
===Primary References===<br />
Brtis, J. S. and M. A. McEvilley 2020. “Unifying Loss-Driven Systems Engineering Activities.” ''INCOSE INSIGHT'', December 9-13. Available at https://www.mitre.org/publications/technical-papers.<br />
<br />
Walden, D. D. et al. 2015. “Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities.” Fourth Edition. San Diego, US-CA: INCOSE.<br />
<br />
Winstead, M. 2020. "An Early Attempt at a Core, Common Set of Loss-Driven Systems Engineering Principles.” ''INCOSE INSIGHT'', December 22-26. Available: https://www.mitre.org/publications/technical-papers <br />
<br />
===Additional References===<br />
None.<br />
<br />
----<br />
<center>[[< Previous Article]] | [[Parent Article]] | [[Next Article >]]</center><br />
<br />
[[Category: Part 5]][[Category:Topic]]<br />
[[Category placeholder]]<br />
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=A_Framework_for_Viewing_Quality_Attributes_from_the_Lens_of_Loss&diff=65900
A Framework for Viewing Quality Attributes from the Lens of Loss
2022-10-10T03:55:44Z
<p>Mhaas: table formatting</p>
<hr />
<div>----<br />
'''''Lead Author:''''' ''John S. Brtis''<br />
----<br />
<br />
Important but often under-considered areas of systems engineering address potential losses associated with the development and use of systems. These areas fall under the rubric of Loss-Driven Systems Engineering (LDSE), the value-adding unification of the systems engineering specialty areas that address the potential losses associated with systems.<br />
<br />
==Overview== <br />
Systems engineering methodologies often focus on the delivery of desired capability. Methodology sources such as the Systems Engineering Handbook (Walden 2015) and ISO/IEC/IEEE 15288 (ISO) provide full lifecycle and fully integrated methodologies that focus on the generation and deployment of a systems to deliver capabilities. Those methodologies are largely capability-driven, and do not provide detailed fully integrated attention to potential loss. Loss and loss-driven specialty areas are largely treated in isolation.<br />
Examples of loss-driven specialty areas include resilience, safety, security, operational risk, environmental protection, quality, and availability. <br />
There is commonality and synergy among these specialty areas, which should be addressed by systems engineering. <br />
Potential synergies include:<br />
* Shared loss scenarios<br />
* Shared requirements<br />
* Shared modeling and analysis techniques<br />
* Shared architecture and design solutions<br />
* Shared risk management<br />
<br />
The expected benefits of applying a unified loss-driven viewpoint in the systems engineering processes include:<br />
* Reducing engineering effort by eliminating redundant efforts among the specialty areas<br />
* Helping to ensure a comprehensive consideration of loss<br />
* Ensuring cohesion and elimination of conflicts among the loss-driven solutions<br />
* Identifying highly effective solutions that address the interests of multiple loss-driven specialty areas<br />
* Providing a holistic viewpoint addressing the multiple perspectives<br />
* Reducing the load of data generated by multiple specialty areas to a minimal, non-redundant set<br />
* Mutual learning among the loss-driven specialty areas <br />
<br />
===Background and Origins===<br />
Engineers at the MITRE Corporation explored the commonality of “protecting against loss” in the areas of security, safety, and resilience as part of an effort to improve a sponsor’s systems engineering methodologies (Brtis 2020). In parallel, these engineers raised and explored the issue with the INCOSE resilience and security working groups. This led to the realization that these specialty areas had commonalities, and synergies with many of the systems engineering specialty areas. The term “loss-driven systems engineering” was coined to identify this area of common interest. <br />
These concepts were discussed with the INCOSE TechOps Director at IS17, and he recommended that the concept be pursued as an INCOSE initiative. An exploratory meeting on LDSE was held at INCOSE IW18. At that meeting participants agreed that this concept should be pursued and decided that as a first step, a special theme issue, on loss-driven systems engineering, of INCOSE ''Insight'' magazine should be pursued, to be followed by a section in the INCOSE SEBOK. That issue of ''Insight'' was published in December 2021.<br />
===The Basis of Commonality===<br />
Systems engineering must address all loss-driven specialty areas in a mutually supportive and optimized manner. The exact definitions and demarcation between the different specialty areas are moot. What matters is meeting all the objectives of the loss-driven areas.<br />
Loss-driven areas often have common objectives, common concepts and principles, common requirements, common architectural solutions, common design solutions, common analyses, and common methodologies. Engineers responsible for loss-driven areas can often do a better job if they work collaboratively. This is because they are all interested in the same overarching concern: addressing potential losses associated with the system of interest. <br />
An inspection of the Systems Engineering Handbook (Walden 2015) identified specialty engineering areas that shared the concerns of loss-driven systems engineering. Those identified include: <br />
* availability<br />
* environmental impact <br />
* maintainability<br />
* resilience engineering<br />
* reliability<br />
* risk management<br />
* system safety engineering<br />
* system security engineering<br />
* quality management<br />
<br />
==Attributes Shared by the Loss-Driven Specialty Areas, a Potential for Unification==<br />
<br />
The loss-driven specialty areas share attributes that specify the scope of each specialty area. All the loss-driven specialty areas have as attributes: <br />
* the types of assets considered<br />
* the types of loss addressed<br />
* the types of adversity addressed <br />
* the coping strategies considered<br />
* the aspects of the system and its environment under consideration <br />
These attributes define the scope of each specialty area. These scopes differ among the loss-driven specialty areas, but in many cases, they overlap. These loss-driven attributes and the possibility of aggregating their overall values, provide a basis for integrating the loss-driven specialty areas, by aggregating the range of values of the parameters and then by addressing their aggregate scopes. Brtis (2020) considers each of these attributes. Figure 1 provides an aggregate summary of the scope of considerations identified for loss-driven attributes. <br />
Properly engineering a system, requires consideration of the full range of each of the loss-driven attributes.<br />
[[File:Loss Driven Systems Engineering Figure 1.png|thumb|center|800px|<center>'''Figure 1: Attributes and Scope of the Integrated Loss-Driven Systems Engineering Problem Space'''</center>]]<br />
<br />
==Core Principles for LDSE==<br />
Winstead (2020) investigated the commonality among principles being articulated for individual loss-driven specialty areas. He identified fundamental principles that can be unified across the specialties. <br />
* Candidate principle 1: Systems engineering minimizes hazards.<br />
* Candidate principle 2: Systems engineering seeks to control hazards that cannot be avoided, including assuring transitions from one known acceptable mode or state to another known and acceptable one.<br />
* Candidate principle 3: Systems engineering uses proven and accepted processes, solutions, methods, materials, etc. when the process, etc. achieves the intended trustworthiness.<br />
* Candidate principle 4: The human within the system should be enabled to prevent, minimize, and recover from loss when possible.<br />
* Candidate principle 5: Systems engineering should strive for the simplest solutions<br />
* Candidate principle 6: Systems engineering produces evolvable systems likely to maintain or improve on loss-driven properties through change.<br />
* Candidate principle 7: Actions should trace to the entity responsible. <br />
* Candidate principle 8: Any critical task should be possible to perform in more than one way.<br />
Winstead (2020) also considered the systems engineering principles of Watson (2019) and discusses minimal changes needed to make them well-suited for application to loss-driven systems engineering. <br />
<br />
==LDSE in the SE Activities==<br />
Brtis (2020) found that several the SE practices identified in ISO 15288 and the INCOSE SE Handbook need to be augmented to adequately address the needs of LDSE and recommended specific additions for the following practice areas. <br />
*Business or Mission Analysis Process<br />
*Stakeholder Needs and Requirements Definition Process<br />
*System Requirements Definition Process<br />
*Architecture Definition Process<br />
*Design Definition Process<br />
*Risk Management Process <br />
<br />
==LDSE Design Techniques==<br />
Winstead (2021) investigates what he calls “loss control” for cyber-physical systems. He investigates loss control independent of any particular systems engineering specialty area. He recommends a set of loss control design principles.<br />
<br />
*'''''Anomaly Detection''''' - Any salient anomaly in the system or in its environment is detected in a timely manner that enables effective response action. <br />
*'''''Commensurate Protection''''' - The strength and type of protection provided to an element must be commensurate with the most significant adverse effect that results from a failure of that element. <br />
*'''''Commensurate Response''''' - The design should match the aggressiveness of an engineered response action’s effect to the needed immediacy to control the effects of each loss scenario. <br />
*'''''Continuous Protection''''' - The protection provided for an element must be effective and uninterrupted during the time that the protection is required. <br />
*'''''Defense-in-depth''''' - Loss is prevented or minimized by employing multiple coordinated techniques and strategies. <br />
*'''''Distributed Privilege''''' - Multiple authorized entities must act in a coordinated manner before an operation on the system is allowed to occur. <br />
*'''''Diversity (Dynamicity) ''''' - The design delivers the required capability through structural, behavioral, data, or control flow variation. <br />
*'''''Domain Separation''''' - Domains with distinctly different protection needs should be physically or logically separated. <br />
*'''''Least Functionality''''' - Each element should have the capability to accomplish its required functions, but no more. <br />
*'''''Least Persistence''''' - System elements and other resources should be available, accessible, and able to fulfill their design intent only for the time they are needed. <br />
*'''''Least Privilege''''' - Each element should be allocated privileges that are necessary to accomplish its specified functions, but no more. <br />
*'''''Least Sharing''''' - System resources should be shared among system elements only when necessary, and among as few system elements as possible. <br />
*'''''Loss Margins''''' - The system is designed to operate in a state space sufficiently distanced below the threshold at which loss occurs. <br />
*'''''Mediated Access''''' - All access to and operations on system elements are mediated. <br />
*'''''Protective Defaults''''' - The default configuration of the system provides maximum protection effectiveness. <br />
*'''''Protective Failure''''' - A failure of a system element should neither result in an unacceptable loss, nor invoke another loss scenario. <br />
*'''''Protective Recovery''''' - The recovery of a system element should not result in, nor lead to, unacceptable loss. <br />
*'''''Redundancy''''' - The design delivers the required capability by the replication of functions or elements. <br />
<br />
==Technical Management Considerations==<br />
The effective coordination and management of LDSE specialty areas – areas that have often operated independently and in isolation of one another -- poses a challenge. <br />
Jackson (2020) discusses the concept of siloism in the context of LDSE projects and ways to mitigate that effect. Siloism is the unwillingness of members of any team to share information. Failure to mitigate siloism can reduce the effectiveness of the entire team. Jackson recommends mitigating siloism using integrated product teams (IPT), which utilize organizational structure and rigorous management to encourage sharing of information among specialties. <br />
Brtis (2021) suggests that for LDSE the systems engineer should holistically consider:<br />
*the full spectrum of adversities<br />
*the full spectrum of weaknesses, defects, flaws, exposures, hazards, and vulnerabilities<br />
*the full spectrum of assets and losses<br />
*the full spectrum of timeframes of interest<br />
*the full spectrum of coping mechanisms<br />
<br />
and further, suggests the systems engineer:<br />
*elicit, analyze, and capture loss-driven requirements as part of the overall stakeholder and system requirements development. <br />
*make the loss-driven architectural decisions holistically across the loss-driven specialty areas<br />
*make the loss-driven design decisions holistically across the loss-driven specialty areas<br />
*integrate the management of risks associated with all loss-driven areas<br />
<br />
Endler (2021) considers real life integration of loss-driven systems engineering activities into system development activities. Challenges identified include lack of appreciation of the importance of loss-driven systems engineering activities and organizational barriers. He finds that existing systems engineering standards poorly describe loss-driven systems engineering activities and fail to integrate loss-drive activities with traditional engineering activities. He proposes methods to overcome those barriers based on widely accepted standards. He offers an approach to accomplish the needed integration with emphasis on the need that loss-driven systems engineers participate throughout the system life cycle and be supported by a common understanding of an integrated approach.<br />
<br />
==Consequences for Model-Based Systems Engineering==<br />
Model-based systems engineering data and models need to be augmented to address the shared attributes of loss-driven systems engineering: assets, losses, adversities, and coping techniques and the common information artifacts identified above. Table 1 identifies some of the additional modeling information (in SysML form) that needs to be captured during the various lifecycle stages to support the effective development and documentation of loss management scenarios and loss management requirements. <br />
<br />
<center>{|<br />
|+'''Table 1. Modeling Information and Artifacts During Lifecycle Phases (Brtis 2020).'''<br />
!Lifecycle Phase<br />
!Artifacts and Information<br />
|-<br />
|Mission and Stakeholder Needs Analysis<br />
|*Add adversities to the context diagram as actors<br />
*Add loss management scenarios as use cases<br />
|-<br />
| Stakeholder <br />
Requirements<br />
|*Develop use case interaction diagrams to document the interaction of actors and architectural modules during the loss management scenarios<br />
*Develop sequence diagrams to represent the activity flow during loss management scenarios<br />
|-<br />
|System Requirements<br />
|*Develop activity diagrams to show the states of the system (and adversities) during loss management scenarios<br />
|-<br />
|Architecture and System Design<br />
|*Develop state models of the loss management scenarios<br />
*Model events and signals among the architectural nodes<br />
|-<br />
|System Design<br />
|*Propose and select loss management design features<br />
*Document loss management related object distribution<br />
|}</center><br />
<br />
==Use Case: Manned Space Rescue Vehicle==<br />
Cureton (2020) explores the applicability of LDSE to a use case, a hypothetical manned space rescue vehicle, via a thought experiment regarding desirable characteristics for achieving resilience, safety, reliability, security, and other loss-driven goals. Various design reference missions are explored for assessment of required loss-driven capabilities in automated flight operations for a hypothetical manned space rescue vehicle.<br />
<br />
==Summary==<br />
Loss-driven systems engineering offers a valuable unification of loss-driven systems engineering specialty areas. Applying this can integrate currently isolated systems engineering activities, leading to improved system effectiveness, and reduced systems engineering costs, while improving the management of potential losses associated with the development and use of systems.<br />
<br />
==References==<br />
===Works Cited===<br />
Cureton, K. L. 2020. “Role of LDSE for a Hypothetical Manned Space Rescue Vehicle.” ''INCOSE INSIGHT,'' December 19-21.<br />
<br />
Brtis, J. S. and M. A. McEvilley. 2019. “Systems Engineering for Resilience,” MITRE Technical Document #190495, The MITRE Corporation. Available: https://www.mitre.org/publications/technical-papers<br />
<br />
Endler, D. 2020. “Integrating Loss-Driven Systems Engineering Activities.” ''INCOSE INSIGHT'', December 14-18.<br />
<br />
ISO (International Organization for Standardization. 2015. ISO/IEC/IEEE 15288:2015. Systems and software engineering – System life cycle processes. Geneva, CH: ISO.<br />
<br />
Jackson, S. 2020. “Loss-Driven Systems Engineering and Siloism.” ''INCOSE INSIGHT,'' December 32-33.<br />
<br />
Watson, Michael D. 2019. "Systems Engineering Principles and Hypotheses." ''INCOSE INSIGHT,'' May 18-28.<br />
<br />
Winstead, M., D. Hild, M. McEvilley, 2021. “Principles of Trustworthy Design of Cyber-Physical Systems.” MITRE Techinical Report #210263, The MITRE Corporation, June 2021. Available: https://www.mitre.org/publications/technical-papers<br />
<br />
===Primary References===<br />
Brtis, J. S. and M. A. McEvilley 2020. “Unifying Loss-Driven Systems Engineering Activities.” ''INCOSE INSIGHT'', December 9-13. Available at https://www.mitre.org/publications/technical-papers.<br />
<br />
Walden, D. D. et al. 2015. “Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities.” Fourth Edition. San Diego, US-CA: INCOSE.<br />
<br />
Winstead, M. 2020. "An Early Attempt at a Core, Common Set of Loss-Driven Systems Engineering Principles.” ''INCOSE INSIGHT'', December 22-26. Available: https://www.mitre.org/publications/technical-papers <br />
<br />
===Additional References===<br />
None.<br />
<br />
----<br />
<center>[[< Previous Article]] | [[Parent Article]] | [[Next Article >]]</center><br />
<br />
[[Category: Part 5]][[Category:Topic]]<br />
[[Category placeholder]]<br />
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=A_Framework_for_Viewing_Quality_Attributes_from_the_Lens_of_Loss&diff=65899
A Framework for Viewing Quality Attributes from the Lens of Loss
2022-10-10T03:54:52Z
<p>Mhaas: Navigation links</p>
<hr />
<div>----<br />
'''''Lead Author:''''' ''John S. Brtis''<br />
----<br />
<br />
Important but often under-considered areas of systems engineering address potential losses associated with the development and use of systems. These areas fall under the rubric of Loss-Driven Systems Engineering (LDSE), the value-adding unification of the systems engineering specialty areas that address the potential losses associated with systems.<br />
<br />
==Overview== <br />
Systems engineering methodologies often focus on the delivery of desired capability. Methodology sources such as the Systems Engineering Handbook (Walden 2015) and ISO/IEC/IEEE 15288 (ISO) provide full lifecycle and fully integrated methodologies that focus on the generation and deployment of a systems to deliver capabilities. Those methodologies are largely capability-driven, and do not provide detailed fully integrated attention to potential loss. Loss and loss-driven specialty areas are largely treated in isolation.<br />
Examples of loss-driven specialty areas include resilience, safety, security, operational risk, environmental protection, quality, and availability. <br />
There is commonality and synergy among these specialty areas, which should be addressed by systems engineering. <br />
Potential synergies include:<br />
* Shared loss scenarios<br />
* Shared requirements<br />
* Shared modeling and analysis techniques<br />
* Shared architecture and design solutions<br />
* Shared risk management<br />
<br />
The expected benefits of applying a unified loss-driven viewpoint in the systems engineering processes include:<br />
* Reducing engineering effort by eliminating redundant efforts among the specialty areas<br />
* Helping to ensure a comprehensive consideration of loss<br />
* Ensuring cohesion and elimination of conflicts among the loss-driven solutions<br />
* Identifying highly effective solutions that address the interests of multiple loss-driven specialty areas<br />
* Providing a holistic viewpoint addressing the multiple perspectives<br />
* Reducing the load of data generated by multiple specialty areas to a minimal, non-redundant set<br />
* Mutual learning among the loss-driven specialty areas <br />
<br />
===Background and Origins===<br />
Engineers at the MITRE Corporation explored the commonality of “protecting against loss” in the areas of security, safety, and resilience as part of an effort to improve a sponsor’s systems engineering methodologies (Brtis 2020). In parallel, these engineers raised and explored the issue with the INCOSE resilience and security working groups. This led to the realization that these specialty areas had commonalities, and synergies with many of the systems engineering specialty areas. The term “loss-driven systems engineering” was coined to identify this area of common interest. <br />
These concepts were discussed with the INCOSE TechOps Director at IS17, and he recommended that the concept be pursued as an INCOSE initiative. An exploratory meeting on LDSE was held at INCOSE IW18. At that meeting participants agreed that this concept should be pursued and decided that as a first step, a special theme issue, on loss-driven systems engineering, of INCOSE ''Insight'' magazine should be pursued, to be followed by a section in the INCOSE SEBOK. That issue of ''Insight'' was published in December 2021.<br />
===The Basis of Commonality===<br />
Systems engineering must address all loss-driven specialty areas in a mutually supportive and optimized manner. The exact definitions and demarcation between the different specialty areas are moot. What matters is meeting all the objectives of the loss-driven areas.<br />
Loss-driven areas often have common objectives, common concepts and principles, common requirements, common architectural solutions, common design solutions, common analyses, and common methodologies. Engineers responsible for loss-driven areas can often do a better job if they work collaboratively. This is because they are all interested in the same overarching concern: addressing potential losses associated with the system of interest. <br />
An inspection of the Systems Engineering Handbook (Walden 2015) identified specialty engineering areas that shared the concerns of loss-driven systems engineering. Those identified include: <br />
* availability<br />
* environmental impact <br />
* maintainability<br />
* resilience engineering<br />
* reliability<br />
* risk management<br />
* system safety engineering<br />
* system security engineering<br />
* quality management<br />
<br />
==Attributes Shared by the Loss-Driven Specialty Areas, a Potential for Unification==<br />
<br />
The loss-driven specialty areas share attributes that specify the scope of each specialty area. All the loss-driven specialty areas have as attributes: <br />
* the types of assets considered<br />
* the types of loss addressed<br />
* the types of adversity addressed <br />
* the coping strategies considered<br />
* the aspects of the system and its environment under consideration <br />
These attributes define the scope of each specialty area. These scopes differ among the loss-driven specialty areas, but in many cases, they overlap. These loss-driven attributes and the possibility of aggregating their overall values, provide a basis for integrating the loss-driven specialty areas, by aggregating the range of values of the parameters and then by addressing their aggregate scopes. Brtis (2020) considers each of these attributes. Figure 1 provides an aggregate summary of the scope of considerations identified for loss-driven attributes. <br />
Properly engineering a system, requires consideration of the full range of each of the loss-driven attributes.<br />
[[File:Loss Driven Systems Engineering Figure 1.png|thumb|center|800px|<center>'''Figure 1: Attributes and Scope of the Integrated Loss-Driven Systems Engineering Problem Space'''</center>]]<br />
<br />
==Core Principles for LDSE==<br />
Winstead (2020) investigated the commonality among principles being articulated for individual loss-driven specialty areas. He identified fundamental principles that can be unified across the specialties. <br />
* Candidate principle 1: Systems engineering minimizes hazards.<br />
* Candidate principle 2: Systems engineering seeks to control hazards that cannot be avoided, including assuring transitions from one known acceptable mode or state to another known and acceptable one.<br />
* Candidate principle 3: Systems engineering uses proven and accepted processes, solutions, methods, materials, etc. when the process, etc. achieves the intended trustworthiness.<br />
* Candidate principle 4: The human within the system should be enabled to prevent, minimize, and recover from loss when possible.<br />
* Candidate principle 5: Systems engineering should strive for the simplest solutions<br />
* Candidate principle 6: Systems engineering produces evolvable systems likely to maintain or improve on loss-driven properties through change.<br />
* Candidate principle 7: Actions should trace to the entity responsible. <br />
* Candidate principle 8: Any critical task should be possible to perform in more than one way.<br />
Winstead (2020) also considered the systems engineering principles of Watson (2019) and discusses minimal changes needed to make them well-suited for application to loss-driven systems engineering. <br />
<br />
==LDSE in the SE Activities==<br />
Brtis (2020) found that several the SE practices identified in ISO 15288 and the INCOSE SE Handbook need to be augmented to adequately address the needs of LDSE and recommended specific additions for the following practice areas. <br />
*Business or Mission Analysis Process<br />
*Stakeholder Needs and Requirements Definition Process<br />
*System Requirements Definition Process<br />
*Architecture Definition Process<br />
*Design Definition Process<br />
*Risk Management Process <br />
<br />
==LDSE Design Techniques==<br />
Winstead (2021) investigates what he calls “loss control” for cyber-physical systems. He investigates loss control independent of any particular systems engineering specialty area. He recommends a set of loss control design principles.<br />
<br />
*'''''Anomaly Detection''''' - Any salient anomaly in the system or in its environment is detected in a timely manner that enables effective response action. <br />
*'''''Commensurate Protection''''' - The strength and type of protection provided to an element must be commensurate with the most significant adverse effect that results from a failure of that element. <br />
*'''''Commensurate Response''''' - The design should match the aggressiveness of an engineered response action’s effect to the needed immediacy to control the effects of each loss scenario. <br />
*'''''Continuous Protection''''' - The protection provided for an element must be effective and uninterrupted during the time that the protection is required. <br />
*'''''Defense-in-depth''''' - Loss is prevented or minimized by employing multiple coordinated techniques and strategies. <br />
*'''''Distributed Privilege''''' - Multiple authorized entities must act in a coordinated manner before an operation on the system is allowed to occur. <br />
*'''''Diversity (Dynamicity) ''''' - The design delivers the required capability through structural, behavioral, data, or control flow variation. <br />
*'''''Domain Separation''''' - Domains with distinctly different protection needs should be physically or logically separated. <br />
*'''''Least Functionality''''' - Each element should have the capability to accomplish its required functions, but no more. <br />
*'''''Least Persistence''''' - System elements and other resources should be available, accessible, and able to fulfill their design intent only for the time they are needed. <br />
*'''''Least Privilege''''' - Each element should be allocated privileges that are necessary to accomplish its specified functions, but no more. <br />
*'''''Least Sharing''''' - System resources should be shared among system elements only when necessary, and among as few system elements as possible. <br />
*'''''Loss Margins''''' - The system is designed to operate in a state space sufficiently distanced below the threshold at which loss occurs. <br />
*'''''Mediated Access''''' - All access to and operations on system elements are mediated. <br />
*'''''Protective Defaults''''' - The default configuration of the system provides maximum protection effectiveness. <br />
*'''''Protective Failure''''' - A failure of a system element should neither result in an unacceptable loss, nor invoke another loss scenario. <br />
*'''''Protective Recovery''''' - The recovery of a system element should not result in, nor lead to, unacceptable loss. <br />
*'''''Redundancy''''' - The design delivers the required capability by the replication of functions or elements. <br />
<br />
==Technical Management Considerations==<br />
The effective coordination and management of LDSE specialty areas – areas that have often operated independently and in isolation of one another -- poses a challenge. <br />
Jackson (2020) discusses the concept of siloism in the context of LDSE projects and ways to mitigate that effect. Siloism is the unwillingness of members of any team to share information. Failure to mitigate siloism can reduce the effectiveness of the entire team. Jackson recommends mitigating siloism using integrated product teams (IPT), which utilize organizational structure and rigorous management to encourage sharing of information among specialties. <br />
Brtis (2021) suggests that for LDSE the systems engineer should holistically consider:<br />
*the full spectrum of adversities<br />
*the full spectrum of weaknesses, defects, flaws, exposures, hazards, and vulnerabilities<br />
*the full spectrum of assets and losses<br />
*the full spectrum of timeframes of interest<br />
*the full spectrum of coping mechanisms<br />
<br />
and further, suggests the systems engineer:<br />
*elicit, analyze, and capture loss-driven requirements as part of the overall stakeholder and system requirements development. <br />
*make the loss-driven architectural decisions holistically across the loss-driven specialty areas<br />
*make the loss-driven design decisions holistically across the loss-driven specialty areas<br />
*integrate the management of risks associated with all loss-driven areas<br />
<br />
Endler (2021) considers real life integration of loss-driven systems engineering activities into system development activities. Challenges identified include lack of appreciation of the importance of loss-driven systems engineering activities and organizational barriers. He finds that existing systems engineering standards poorly describe loss-driven systems engineering activities and fail to integrate loss-drive activities with traditional engineering activities. He proposes methods to overcome those barriers based on widely accepted standards. He offers an approach to accomplish the needed integration with emphasis on the need that loss-driven systems engineers participate throughout the system life cycle and be supported by a common understanding of an integrated approach.<br />
<br />
==Consequences for Model-Based Systems Engineering==<br />
Model-based systems engineering data and models need to be augmented to address the shared attributes of loss-driven systems engineering: assets, losses, adversities, and coping techniques and the common information artifacts identified above. Table 1 identifies some of the additional modeling information (in SysML form) that needs to be captured during the various lifecycle stages to support the effective development and documentation of loss management scenarios and loss management requirements. <br />
<br />
{|<br />
|+'''Table 1. Modeling Information and Artifacts During Lifecycle Phases (Brtis 2020).'''<br />
!Lifecycle Phase<br />
!Artifacts and Information<br />
|-<br />
|Mission and Stakeholder Needs Analysis<br />
|*Add adversities to the context diagram as actors<br />
*Add loss management scenarios as use cases<br />
|-<br />
| Stakeholder <br />
Requirements<br />
|*Develop use case interaction diagrams to document the interaction of actors and architectural modules during the loss management scenarios<br />
*Develop sequence diagrams to represent the activity flow during loss management scenarios<br />
|-<br />
|System Requirements<br />
|*Develop activity diagrams to show the states of the system (and adversities) during loss management scenarios<br />
|-<br />
|Architecture and System Design<br />
|*Develop state models of the loss management scenarios<br />
*Model events and signals among the architectural nodes<br />
|-<br />
|System Design<br />
|*Propose and select loss management design features<br />
*Document loss management related object distribution<br />
|}<br />
<br />
==Use Case: Manned Space Rescue Vehicle==<br />
Cureton (2020) explores the applicability of LDSE to a use case, a hypothetical manned space rescue vehicle, via a thought experiment regarding desirable characteristics for achieving resilience, safety, reliability, security, and other loss-driven goals. Various design reference missions are explored for assessment of required loss-driven capabilities in automated flight operations for a hypothetical manned space rescue vehicle.<br />
<br />
==Summary==<br />
Loss-driven systems engineering offers a valuable unification of loss-driven systems engineering specialty areas. Applying this can integrate currently isolated systems engineering activities, leading to improved system effectiveness, and reduced systems engineering costs, while improving the management of potential losses associated with the development and use of systems.<br />
<br />
==References==<br />
===Works Cited===<br />
Cureton, K. L. 2020. “Role of LDSE for a Hypothetical Manned Space Rescue Vehicle.” ''INCOSE INSIGHT,'' December 19-21.<br />
<br />
Brtis, J. S. and M. A. McEvilley. 2019. “Systems Engineering for Resilience,” MITRE Technical Document #190495, The MITRE Corporation. Available: https://www.mitre.org/publications/technical-papers<br />
<br />
Endler, D. 2020. “Integrating Loss-Driven Systems Engineering Activities.” ''INCOSE INSIGHT'', December 14-18.<br />
<br />
ISO (International Organization for Standardization. 2015. ISO/IEC/IEEE 15288:2015. Systems and software engineering – System life cycle processes. Geneva, CH: ISO.<br />
<br />
Jackson, S. 2020. “Loss-Driven Systems Engineering and Siloism.” ''INCOSE INSIGHT,'' December 32-33.<br />
<br />
Watson, Michael D. 2019. "Systems Engineering Principles and Hypotheses." ''INCOSE INSIGHT,'' May 18-28.<br />
<br />
Winstead, M., D. Hild, M. McEvilley, 2021. “Principles of Trustworthy Design of Cyber-Physical Systems.” MITRE Techinical Report #210263, The MITRE Corporation, June 2021. Available: https://www.mitre.org/publications/technical-papers<br />
<br />
===Primary References===<br />
Brtis, J. S. and M. A. McEvilley 2020. “Unifying Loss-Driven Systems Engineering Activities.” ''INCOSE INSIGHT'', December 9-13. Available at https://www.mitre.org/publications/technical-papers.<br />
<br />
Walden, D. D. et al. 2015. “Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities.” Fourth Edition. San Diego, US-CA: INCOSE.<br />
<br />
Winstead, M. 2020. "An Early Attempt at a Core, Common Set of Loss-Driven Systems Engineering Principles.” ''INCOSE INSIGHT'', December 22-26. Available: https://www.mitre.org/publications/technical-papers <br />
<br />
===Additional References===<br />
None.<br />
<br />
----<br />
<center>[[< Previous Article]] | [[Parent Article]] | [[Next Article >]]</center><br />
<br />
[[Category: Part 5]][[Category:Topic]]<br />
[[Category placeholder]]<br />
<center>'''SEBoK v. 2.7, released 31 October 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=A_Framework_for_Viewing_Quality_Attributes_from_the_Lens_of_Loss&diff=65896
A Framework for Viewing Quality Attributes from the Lens of Loss
2022-10-10T03:51:51Z
<p>Mhaas: </p>
<hr />
<div>----<br />
'''''Lead Author:''''' ''John S. Brtis''<br />
----<br />
<br />
Important but often under-considered areas of systems engineering address potential losses associated with the development and use of systems. These areas fall under the rubric of Loss-Driven Systems Engineering (LDSE), the value-adding unification of the systems engineering specialty areas that address the potential losses associated with systems.<br />
<br />
==Overview== <br />
Systems engineering methodologies often focus on the delivery of desired capability. Methodology sources such as the Systems Engineering Handbook (Walden 2015) and ISO/IEC/IEEE 15288 (ISO) provide full lifecycle and fully integrated methodologies that focus on the generation and deployment of a systems to deliver capabilities. Those methodologies are largely capability-driven, and do not provide detailed fully integrated attention to potential loss. Loss and loss-driven specialty areas are largely treated in isolation.<br />
Examples of loss-driven specialty areas include resilience, safety, security, operational risk, environmental protection, quality, and availability. <br />
There is commonality and synergy among these specialty areas, which should be addressed by systems engineering. <br />
Potential synergies include:<br />
* Shared loss scenarios<br />
* Shared requirements<br />
* Shared modeling and analysis techniques<br />
* Shared architecture and design solutions<br />
* Shared risk management<br />
<br />
The expected benefits of applying a unified loss-driven viewpoint in the systems engineering processes include:<br />
* Reducing engineering effort by eliminating redundant efforts among the specialty areas<br />
* Helping to ensure a comprehensive consideration of loss<br />
* Ensuring cohesion and elimination of conflicts among the loss-driven solutions<br />
* Identifying highly effective solutions that address the interests of multiple loss-driven specialty areas<br />
* Providing a holistic viewpoint addressing the multiple perspectives<br />
* Reducing the load of data generated by multiple specialty areas to a minimal, non-redundant set<br />
* Mutual learning among the loss-driven specialty areas <br />
<br />
===Background and Origins===<br />
Engineers at the MITRE Corporation explored the commonality of “protecting against loss” in the areas of security, safety, and resilience as part of an effort to improve a sponsor’s systems engineering methodologies (Brtis 2020). In parallel, these engineers raised and explored the issue with the INCOSE resilience and security working groups. This led to the realization that these specialty areas had commonalities, and synergies with many of the systems engineering specialty areas. The term “loss-driven systems engineering” was coined to identify this area of common interest. <br />
These concepts were discussed with the INCOSE TechOps Director at IS17, and he recommended that the concept be pursued as an INCOSE initiative. An exploratory meeting on LDSE was held at INCOSE IW18. At that meeting participants agreed that this concept should be pursued and decided that as a first step, a special theme issue, on loss-driven systems engineering, of INCOSE ''Insight'' magazine should be pursued, to be followed by a section in the INCOSE SEBOK. That issue of ''Insight'' was published in December 2021.<br />
===The Basis of Commonality===<br />
Systems engineering must address all loss-driven specialty areas in a mutually supportive and optimized manner. The exact definitions and demarcation between the different specialty areas are moot. What matters is meeting all the objectives of the loss-driven areas.<br />
Loss-driven areas often have common objectives, common concepts and principles, common requirements, common architectural solutions, common design solutions, common analyses, and common methodologies. Engineers responsible for loss-driven areas can often do a better job if they work collaboratively. This is because they are all interested in the same overarching concern: addressing potential losses associated with the system of interest. <br />
An inspection of the Systems Engineering Handbook (Walden 2015) identified specialty engineering areas that shared the concerns of loss-driven systems engineering. Those identified include: <br />
* availability<br />
* environmental impact <br />
* maintainability<br />
* resilience engineering<br />
* reliability<br />
* risk management<br />
* system safety engineering<br />
* system security engineering<br />
* quality management<br />
<br />
==Attributes Shared by the Loss-Driven Specialty Areas, a Potential for Unification==<br />
<br />
The loss-driven specialty areas share attributes that specify the scope of each specialty area. All the loss-driven specialty areas have as attributes: <br />
* the types of assets considered<br />
* the types of loss addressed<br />
* the types of adversity addressed <br />
* the coping strategies considered<br />
* the aspects of the system and its environment under consideration <br />
These attributes define the scope of each specialty area. These scopes differ among the loss-driven specialty areas, but in many cases, they overlap. These loss-driven attributes and the possibility of aggregating their overall values, provide a basis for integrating the loss-driven specialty areas, by aggregating the range of values of the parameters and then by addressing their aggregate scopes. Brtis (2020) considers each of these attributes. Figure 1 provides an aggregate summary of the scope of considerations identified for loss-driven attributes. <br />
Properly engineering a system, requires consideration of the full range of each of the loss-driven attributes.<br />
[[File:Loss Driven Systems Engineering Figure 1.png|thumb|center|800px|<center>'''Figure 1: Attributes and Scope of the Integrated Loss-Driven Systems Engineering Problem Space'''</center>]]<br />
<br />
==Core Principles for LDSE==<br />
Winstead (2020) investigated the commonality among principles being articulated for individual loss-driven specialty areas. He identified fundamental principles that can be unified across the specialties. <br />
* Candidate principle 1: Systems engineering minimizes hazards.<br />
* Candidate principle 2: Systems engineering seeks to control hazards that cannot be avoided, including assuring transitions from one known acceptable mode or state to another known and acceptable one.<br />
* Candidate principle 3: Systems engineering uses proven and accepted processes, solutions, methods, materials, etc. when the process, etc. achieves the intended trustworthiness.<br />
* Candidate principle 4: The human within the system should be enabled to prevent, minimize, and recover from loss when possible.<br />
* Candidate principle 5: Systems engineering should strive for the simplest solutions<br />
* Candidate principle 6: Systems engineering produces evolvable systems likely to maintain or improve on loss-driven properties through change.<br />
* Candidate principle 7: Actions should trace to the entity responsible. <br />
* Candidate principle 8: Any critical task should be possible to perform in more than one way.<br />
Winstead (2020) also considered the systems engineering principles of Watson (2019) and discusses minimal changes needed to make them well-suited for application to loss-driven systems engineering. <br />
<br />
==LDSE in the SE Activities==<br />
Brtis (2020) found that several the SE practices identified in ISO 15288 and the INCOSE SE Handbook need to be augmented to adequately address the needs of LDSE and recommended specific additions for the following practice areas. <br />
*Business or Mission Analysis Process<br />
*Stakeholder Needs and Requirements Definition Process<br />
*System Requirements Definition Process<br />
*Architecture Definition Process<br />
*Design Definition Process<br />
*Risk Management Process <br />
<br />
==LDSE Design Techniques==<br />
Winstead (2021) investigates what he calls “loss control” for cyber-physical systems. He investigates loss control independent of any particular systems engineering specialty area. He recommends a set of loss control design principles.<br />
<br />
*'''''Anomaly Detection''''' - Any salient anomaly in the system or in its environment is detected in a timely manner that enables effective response action. <br />
*'''''Commensurate Protection''''' - The strength and type of protection provided to an element must be commensurate with the most significant adverse effect that results from a failure of that element. <br />
*'''''Commensurate Response''''' - The design should match the aggressiveness of an engineered response action’s effect to the needed immediacy to control the effects of each loss scenario. <br />
*'''''Continuous Protection''''' - The protection provided for an element must be effective and uninterrupted during the time that the protection is required. <br />
*'''''Defense-in-depth''''' - Loss is prevented or minimized by employing multiple coordinated techniques and strategies. <br />
*'''''Distributed Privilege''''' - Multiple authorized entities must act in a coordinated manner before an operation on the system is allowed to occur. <br />
*'''''Diversity (Dynamicity) ''''' - The design delivers the required capability through structural, behavioral, data, or control flow variation. <br />
*'''''Domain Separation''''' - Domains with distinctly different protection needs should be physically or logically separated. <br />
*'''''Least Functionality''''' - Each element should have the capability to accomplish its required functions, but no more. <br />
*'''''Least Persistence''''' - System elements and other resources should be available, accessible, and able to fulfill their design intent only for the time they are needed. <br />
*'''''Least Privilege''''' - Each element should be allocated privileges that are necessary to accomplish its specified functions, but no more. <br />
*'''''Least Sharing''''' - System resources should be shared among system elements only when necessary, and among as few system elements as possible. <br />
*'''''Loss Margins''''' - The system is designed to operate in a state space sufficiently distanced below the threshold at which loss occurs. <br />
*'''''Mediated Access''''' - All access to and operations on system elements are mediated. <br />
*'''''Protective Defaults''''' - The default configuration of the system provides maximum protection effectiveness. <br />
*'''''Protective Failure''''' - A failure of a system element should neither result in an unacceptable loss, nor invoke another loss scenario. <br />
*'''''Protective Recovery''''' - The recovery of a system element should not result in, nor lead to, unacceptable loss. <br />
*'''''Redundancy''''' - The design delivers the required capability by the replication of functions or elements. <br />
<br />
==Technical Management Considerations==<br />
The effective coordination and management of LDSE specialty areas – areas that have often operated independently and in isolation of one another -- poses a challenge. <br />
Jackson (2020) discusses the concept of siloism in the context of LDSE projects and ways to mitigate that effect. Siloism is the unwillingness of members of any team to share information. Failure to mitigate siloism can reduce the effectiveness of the entire team. Jackson recommends mitigating siloism using integrated product teams (IPT), which utilize organizational structure and rigorous management to encourage sharing of information among specialties. <br />
Brtis (2021) suggests that for LDSE the systems engineer should holistically consider:<br />
*the full spectrum of adversities<br />
*the full spectrum of weaknesses, defects, flaws, exposures, hazards, and vulnerabilities<br />
*the full spectrum of assets and losses<br />
*the full spectrum of timeframes of interest<br />
*the full spectrum of coping mechanisms<br />
<br />
and further, suggests the systems engineer:<br />
*elicit, analyze, and capture loss-driven requirements as part of the overall stakeholder and system requirements development. <br />
*make the loss-driven architectural decisions holistically across the loss-driven specialty areas<br />
*make the loss-driven design decisions holistically across the loss-driven specialty areas<br />
*integrate the management of risks associated with all loss-driven areas<br />
<br />
Endler (2021) considers real life integration of loss-driven systems engineering activities into system development activities. Challenges identified include lack of appreciation of the importance of loss-driven systems engineering activities and organizational barriers. He finds that existing systems engineering standards poorly describe loss-driven systems engineering activities and fail to integrate loss-drive activities with traditional engineering activities. He proposes methods to overcome those barriers based on widely accepted standards. He offers an approach to accomplish the needed integration with emphasis on the need that loss-driven systems engineers participate throughout the system life cycle and be supported by a common understanding of an integrated approach.<br />
<br />
==Consequences for Model-Based Systems Engineering==<br />
Model-based systems engineering data and models need to be augmented to address the shared attributes of loss-driven systems engineering: assets, losses, adversities, and coping techniques and the common information artifacts identified above. Table 1 identifies some of the additional modeling information (in SysML form) that needs to be captured during the various lifecycle stages to support the effective development and documentation of loss management scenarios and loss management requirements. <br />
<br />
{|<br />
|+'''Table 1. Modeling Information and Artifacts During Lifecycle Phases (Brtis 2020).'''.<br />
!Lifecycle Phase<br />
!Artifacts and Information<br />
|-<br />
|Mission and Stakeholder Needs Analysis<br />
|*Add adversities to the context diagram as actors<br />
*Add loss management scenarios as use cases<br />
|-<br />
| Stakeholder <br />
Requirements<br />
|*Develop use case interaction diagrams to document the interaction of actors and architectural modules during the loss management scenarios<br />
*Develop sequence diagrams to represent the activity flow during loss management scenarios<br />
|-<br />
|System Requirements<br />
|*Develop activity diagrams to show the states of the system (and adversities) during loss management scenarios<br />
|-<br />
|Architecture and System Design<br />
|*Develop state models of the loss management scenarios<br />
*Model events and signals among the architectural nodes<br />
|-<br />
|System Design<br />
|*Propose and select loss management design features<br />
*Document loss management related object distribution<br />
|}<br />
<br />
==Use Case: Manned Space Rescue Vehicle==<br />
Cureton (2020) explores the applicability of LDSE to a use case, a hypothetical manned space rescue vehicle, via a thought experiment regarding desirable characteristics for achieving resilience, safety, reliability, security, and other loss-driven goals. Various design reference missions are explored for assessment of required loss-driven capabilities in automated flight operations for a hypothetical manned space rescue vehicle.<br />
<br />
==Summary==<br />
Loss-driven systems engineering offers a valuable unification of loss-driven systems engineering specialty areas. Applying this can integrate currently isolated systems engineering activities, leading to improved system effectiveness, and reduced systems engineering costs, while improving the management of potential losses associated with the development and use of systems.<br />
<br />
==References==<br />
===Works Cited===<br />
Cureton, K. L. 2020. “Role of LDSE for a Hypothetical Manned Space Rescue Vehicle.” ''INCOSE INSIGHT,'' December 19-21.<br />
<br />
Brtis, J. S. and M. A. McEvilley. 2019. “Systems Engineering for Resilience,” MITRE Technical Document #190495, The MITRE Corporation. Available: https://www.mitre.org/publications/technical-papers<br />
<br />
Endler, D. 2020. “Integrating Loss-Driven Systems Engineering Activities.” ''INCOSE INSIGHT'', December 14-18.<br />
<br />
ISO (International Organization for Standardization. 2015. ISO/IEC/IEEE 15288:2015. Systems and software engineering – System life cycle processes. Geneva, CH: ISO.<br />
<br />
Jackson, S. 2020. “Loss-Driven Systems Engineering and Siloism.” ''INCOSE INSIGHT,'' December 32-33.<br />
<br />
Watson, Michael D. 2019. "Systems Engineering Principles and Hypotheses." ''INCOSE INSIGHT,'' May 18-28.<br />
<br />
Winstead, M., D. Hild, M. McEvilley, 2021. “Principles of Trustworthy Design of Cyber-Physical Systems.” MITRE Techinical Report #210263, The MITRE Corporation, June 2021. Available: https://www.mitre.org/publications/technical-papers<br />
<br />
===Primary References===<br />
Brtis, J. S. and M. A. McEvilley 2020. “Unifying Loss-Driven Systems Engineering Activities.” ''INCOSE INSIGHT'', December 9-13. Available at https://www.mitre.org/publications/technical-papers.<br />
<br />
Walden, D. D. et al. 2015. “Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities.” Fourth Edition. San Diego, US-CA: INCOSE.<br />
<br />
Winstead, M. 2020. "An Early Attempt at a Core, Common Set of Loss-Driven Systems Engineering Principles.” ''INCOSE INSIGHT'', December 22-26. Available: https://www.mitre.org/publications/technical-papers <br />
<br />
===Additional References===<br />
None.</div>
Mhaas
https://sebokwiki.org/w/index.php?title=A_Framework_for_Viewing_Quality_Attributes_from_the_Lens_of_Loss&diff=65891
A Framework for Viewing Quality Attributes from the Lens of Loss
2022-10-10T03:37:28Z
<p>Mhaas: Added updated content</p>
<hr />
<div>----<br />
'''''Lead Author:''''' ''John S. Brtis''<br />
----<br />
<br />
Important but often under-considered areas of systems engineering address potential losses associated with the development and use of systems. These areas fall under the rubric of Loss-Driven Systems Engineering (LDSE), the value-adding unification of the systems engineering specialty areas that address the potential losses associated with systems.<br />
<br />
==Overview== <br />
Systems engineering methodologies often focus on the delivery of desired capability. Methodology sources such as the Systems Engineering Handbook (Walden 2015) and ISO/IEC/IEEE 15288 (ISO) provide full lifecycle and fully integrated methodologies that focus on the generation and deployment of a systems to deliver capabilities. Those methodologies are largely capability-driven, and do not provide detailed fully integrated attention to potential loss. Loss and loss-driven specialty areas are largely treated in isolation.<br />
Examples of loss-driven specialty areas include resilience, safety, security, operational risk, environmental protection, quality, and availability. <br />
There is commonality and synergy among these specialty areas, which should be addressed by systems engineering. <br />
Potential synergies include:<br />
* Shared loss scenarios<br />
* Shared requirements<br />
* Shared modeling and analysis techniques<br />
* Shared architecture and design solutions<br />
* Shared risk management<br />
<br />
The expected benefits of applying a unified loss-driven viewpoint in the systems engineering processes include:<br />
* Reducing engineering effort by eliminating redundant efforts among the specialty areas<br />
* Helping to ensure a comprehensive consideration of loss<br />
* Ensuring cohesion and elimination of conflicts among the loss-driven solutions<br />
* Identifying highly effective solutions that address the interests of multiple loss-driven specialty areas<br />
* Providing a holistic viewpoint addressing the multiple perspectives<br />
* Reducing the load of data generated by multiple specialty areas to a minimal, non-redundant set<br />
* Mutual learning among the loss-driven specialty areas <br />
<br />
===Background and Origins===<br />
Engineers at the MITRE Corporation explored the commonality of “protecting against loss” in the areas of security, safety, and resilience as part of an effort to improve a sponsor’s systems engineering methodologies (Brtis 2020). In parallel, these engineers raised and explored the issue with the INCOSE resilience and security working groups. This led to the realization that these specialty areas had commonalities, and synergies with many of the systems engineering specialty areas. The term “loss-driven systems engineering” was coined to identify this area of common interest. <br />
These concepts were discussed with the INCOSE TechOps Director at IS17, and he recommended that the concept be pursued as an INCOSE initiative. An exploratory meeting on LDSE was held at INCOSE IW18. At that meeting participants agreed that this concept should be pursued and decided that as a first step, a special theme issue, on loss-driven systems engineering, of INCOSE ''Insight'' magazine should be pursued, to be followed by a section in the INCOSE SEBOK. That issue of ''Insight'' was published in December 2021.<br />
===The Basis of Commonality===<br />
Systems engineering must address all loss-driven specialty areas in a mutually supportive and optimized manner. The exact definitions and demarcation between the different specialty areas are moot. What matters is meeting all the objectives of the loss-driven areas.<br />
Loss-driven areas often have common objectives, common concepts and principles, common requirements, common architectural solutions, common design solutions, common analyses, and common methodologies. Engineers responsible for loss-driven areas can often do a better job if they work collaboratively. This is because they are all interested in the same overarching concern: addressing potential losses associated with the system of interest. <br />
An inspection of the Systems Engineering Handbook (Walden 2015) identified specialty engineering areas that shared the concerns of loss-driven systems engineering. Those identified include: <br />
* availability<br />
* environmental impact <br />
* maintainability<br />
* resilience engineering<br />
* reliability<br />
* risk management<br />
* system safety engineering<br />
* system security engineering<br />
* quality management<br />
<br />
==Attributes Shared by the Loss-Driven Specialty Areas, a Potential for Unification==<br />
<br />
The loss-driven specialty areas share attributes that specify the scope of each specialty area. All the loss-driven specialty areas have as attributes: <br />
* the types of assets considered<br />
* the types of loss addressed<br />
* the types of adversity addressed <br />
* the coping strategies considered<br />
* the aspects of the system and its environment under consideration <br />
These attributes define the scope of each specialty area. These scopes differ among the loss-driven specialty areas, but in many cases, they overlap. These loss-driven attributes and the possibility of aggregating their overall values, provide a basis for integrating the loss-driven specialty areas, by aggregating the range of values of the parameters and then by addressing their aggregate scopes. Brtis (2020) considers each of these attributes. Figure 1 provides an aggregate summary of the scope of considerations identified for loss-driven attributes. <br />
Properly engineering a system, requires consideration of the full range of each of the loss-driven attributes.<br />
[[File:Loss Driven Systems Engineering Figure 1.png|thumb|center|800px|<center>'''Figure 1: Attributes and Scope of the Integrated Loss-Driven Systems Engineering Problem Space'''</center>]]<br />
==Core Principles for LDSE==<br />
Winstead (2020) investigated the commonality among principles being articulated for individual loss-driven specialty areas. He identified fundamental principles that can be unified across the specialties. <br />
* Candidate principle 1: Systems engineering minimizes hazards.<br />
* Candidate principle 2: Systems engineering seeks to control hazards that cannot be avoided, including assuring transitions from one known acceptable mode or state to another known and acceptable one.<br />
* Candidate principle 3: Systems engineering uses proven and accepted processes, solutions, methods, materials, etc. when the process, etc. achieves the intended trustworthiness.<br />
* Candidate principle 4: The human within the system should be enabled to prevent, minimize, and recover from loss when possible.<br />
* Candidate principle 5: Systems engineering should strive for the simplest solutions<br />
* Candidate principle 6: Systems engineering produces evolvable systems likely to maintain or improve on loss-driven properties through change.<br />
* Candidate principle 7: Actions should trace to the entity responsible. <br />
* Candidate principle 8: Any critical task should be possible to perform in more than one way.<br />
Winstead (2020) also considered the systems engineering principles of Watson (2019) and discusses minimal changes needed to make them well-suited for application to loss-driven systems engineering. <br />
==LDSE in the SE Activities==<br />
Brtis (2020) found that several the SE practices identified in ISO 15288 and the INCOSE SE Handbook need to be augmented to adequately address the needs of LDSE and recommended specific additions for the following practice areas. <br />
*Business or Mission Analysis Process<br />
*Stakeholder Needs and Requirements Definition Process<br />
*System Requirements Definition Process<br />
*Architecture Definition Process<br />
*Design Definition Process<br />
*Risk Management Process <br />
<br />
==LDSE Design Techniques==<br />
<br />
Winstead (2021) investigates what he calls “loss control” for cyber-physical systems. He investigates loss control independent of any particular systems engineering specialty area. He recommends a set of loss control design principles.<br />
<br />
*'''''Anomaly Detection''''' - Any salient anomaly in the system or in its environment is detected in a timely manner that enables effective response action. <br />
*'''''Commensurate Protection''''' - The strength and type of protection provided to an element must be commensurate with the most significant adverse effect that results from a failure of that element. <br />
*'''''Commensurate Response''''' - The design should match the aggressiveness of an engineered response action’s effect to the needed immediacy to control the effects of each loss scenario. <br />
*'''''Continuous Protection''''' - The protection provided for an element must be effective and uninterrupted during the time that the protection is required. <br />
*'''''Defense-in-depth''''' - Loss is prevented or minimized by employing multiple coordinated techniques and strategies. <br />
*'''''Distributed Privilege''''' - Multiple authorized entities must act in a coordinated manner before an operation on the system is allowed to occur. <br />
*'''''Diversity (Dynamicity) ''''' - The design delivers the required capability through structural, behavioral, data, or control flow variation. <br />
*'''''Domain Separation''''' - Domains with distinctly different protection needs should be physically or logically separated. <br />
*'''''Least Functionality''''' - Each element should have the capability to accomplish its required functions, but no more. <br />
*'''''Least Persistence''''' - System elements and other resources should be available, accessible, and able to fulfill their design intent only for the time they are needed. <br />
*'''''Least Privilege''''' - Each element should be allocated privileges that are necessary to accomplish its specified functions, but no more. <br />
*'''''Least Sharing''''' - System resources should be shared among system elements only when necessary, and among as few system elements as possible. <br />
*'''''Loss Margins''''' - The system is designed to operate in a state space sufficiently distanced below the threshold at which loss occurs. <br />
*'''''Mediated Access''''' - All access to and operations on system elements are mediated. <br />
*'''''Protective Defaults''''' - The default configuration of the system provides maximum protection effectiveness. <br />
*'''''Protective Failure''''' - A failure of a system element should neither result in an unacceptable loss, nor invoke another loss scenario. <br />
*'''''Protective Recovery''''' - The recovery of a system element should not result in, nor lead to, unacceptable loss. <br />
*'''''Redundancy''''' - The design delivers the required capability by the replication of functions or elements. <br />
<br />
==Technical Management Considerations==<br />
<br />
The effective coordination and management of LDSE specialty areas – areas that have often operated independently and in isolation of one another -- poses a challenge. <br />
Jackson (2020) discusses the concept of siloism in the context of LDSE projects and ways to mitigate that effect. Siloism is the unwillingness of members of any team to share information. Failure to mitigate siloism can reduce the effectiveness of the entire team. Jackson recommends mitigating siloism using integrated product teams (IPT), which utilize organizational structure and rigorous management to encourage sharing of information among specialties. <br />
Brtis (2021) suggests that for LDSE the systems engineer should holistically consider:<br />
*the full spectrum of adversities<br />
*the full spectrum of weaknesses, defects, flaws, exposures, hazards, and vulnerabilities<br />
*the full spectrum of assets and losses<br />
*the full spectrum of timeframes of interest<br />
*the full spectrum of coping mechanisms<br />
<br />
and further, suggests the systems engineer:<br />
*elicit, analyze, and capture loss-driven requirements as part of the overall stakeholder and system requirements development. <br />
*make the loss-driven architectural decisions holistically across the loss-driven specialty areas<br />
*make the loss-driven design decisions holistically across the loss-driven specialty areas<br />
*integrate the management of risks associated with all loss-driven areas<br />
<br />
Endler (2021) considers real life integration of loss-driven systems engineering activities into system development activities. Challenges identified include lack of appreciation of the importance of loss-driven systems engineering activities and organizational barriers. He finds that existing systems engineering standards poorly describe loss-driven systems engineering activities and fail to integrate loss-drive activities with traditional engineering activities. He proposes methods to overcome those barriers based on widely accepted standards. He offers an approach to accomplish the needed integration with emphasis on the need that loss-driven systems engineers participate throughout the system life cycle and be supported by a common understanding of an integrated approach.<br />
==Consequences for Model-Based Systems Engineering==<br />
Model-based systems engineering data and models need to be augmented to address the shared attributes of loss-driven systems engineering: assets, losses, adversities, and coping techniques and the common information artifacts identified above. Table 1 identifies some of the additional modeling information (in SysML form) that needs to be captured during the various lifecycle stages to support the effective development and documentation of loss management scenarios and loss management requirements. <br />
<br />
{|<br />
|+'''Table 1. Modeling Information and Artifacts During Lifecycle Phases (Brtis 2020).'''.<br />
!Lifecycle Phase<br />
!Artifacts and Information<br />
|-<br />
|Mission and Stakeholder Needs Analysis<br />
|*Add adversities to the context diagram as actors<br />
*Add loss management scenarios as use cases<br />
|-<br />
| Stakeholder <br />
Requirements<br />
|*Develop use case interaction diagrams to document the interaction of actors and architectural modules during the loss management scenarios<br />
*Develop sequence diagrams to represent the activity flow during loss management scenarios<br />
|-<br />
|System Requirements<br />
|*Develop activity diagrams to show the states of the system (and adversities) during loss management scenarios<br />
|-<br />
|Architecture and System Design<br />
|*Develop state models of the loss management scenarios<br />
*Model events and signals among the architectural nodes<br />
|-<br />
|System Design<br />
|*Propose and select loss management design features<br />
*Document loss management related object distribution<br />
|}<br />
<br />
==Use Case: Manned Space Rescue Vehicle==<br />
Cureton (2020) explores the applicability of LDSE to a use case, a hypothetical manned space rescue vehicle, via a thought experiment regarding desirable characteristics for achieving resilience, safety, reliability, security, and other loss-driven goals. Various design reference missions are explored for assessment of required loss-driven capabilities in automated flight operations for a hypothetical manned space rescue vehicle.<br />
==Summary==<br />
Loss-driven systems engineering offers a valuable unification of loss-driven systems engineering specialty areas. Applying this can integrate currently isolated systems engineering activities, leading to improved system effectiveness, and reduced systems engineering costs, while improving the management of potential losses associated with the development and use of systems.<br />
==References==<br />
===Works Cited===<br />
Cureton, K. L. 2020. “Role of LDSE for a Hypothetical Manned Space Rescue Vehicle.” INCOSE INSIGHT, December 19-21.<br />
Brtis, J. S. and M. A. McEvilley. 2019. “Systems Engineering for Resilience,” MITRE Technical Document #190495, The MITRE Corporation. Available at https://www.mitre.org/publications/technical-papers. <br />
Endler, D. 2020. “Integrating Loss-Driven Systems Engineering Activities.” INCOSE INSIGHT, December 14-18.<br />
ISO (International Organization for Standardization. 2015. ISO/IEC/IEEE 15288:2015. Systems and software engineering – System life cycle processes. Geneva, CH: ISO.<br />
Jackson, S. 2020. “Loss-Driven Systems Engineering and Siloism.” INCOSE INSIGHT, December 32-33.<br />
Watson, Michael D. 2019. "Systems Engineering Principles and Hypotheses." INCOSE INSIGHT, May: 18-28.<br />
Winstead, M., D. Hild, M. McEvilley, 2021. “Principles of Trustworthy Design of Cyber-Physical Systems.” MITRE Techinical Report #210263, The MITRE Corporation, June 2021. Available at https://www.mitre.org/publications/technical-papers.<br />
<br />
===Primary References===<br />
Brtis, J. S. and M. A. McEvilley 2020. “Unifying Loss-Driven Systems Engineering Activities.” INCOSE INSIGHT, December 9-13. Available at https://www.mitre.org/publications/technical-papers.<br />
<br />
Walden, D. D. el.al. 2015. “Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities.” Fourth Edition. San Diego, US-CA: INCOSE.<br />
<br />
Winstead, M. 2020. An Early Attempt at a Core, Common Set of Loss-Driven Systems Engineering Principles.” INCOSE INSIGHT, December 22-26. Available at https://www.mitre.org/publications/technical-papers.<br />
<br />
===Additional References===<br />
None.</div>
Mhaas
https://sebokwiki.org/w/index.php?title=File:Loss_Driven_Systems_Engineering_Figure_1.png&diff=65817
File:Loss Driven Systems Engineering Figure 1.png
2022-10-09T04:22:51Z
<p>Mhaas: Uploaded own work with UploadWizard</p>
<hr />
<div>=={{int:filedesc}}==<br />
{{Information<br />
|description={{en|1=Author - John S. Brtis}}<br />
|date=2022-10-09<br />
|source={{own}}<br />
|author=[[User:Mhaas|Mhaas]]<br />
|permission=<br />
|other versions=<br />
}}<br />
<br />
=={{int:license-header}}==<br />
{{licensing|generic}}</div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Quality_Attributes&diff=65028
Systems Engineering and Quality Attributes
2022-05-18T13:07:26Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div>----<br />
'''''Lead Authors:''''' ''Art Pyster and Dave Olwell'' '''''Contributing Authors:''''' ''Richard Turner, Dick Fairley, Scott Jackson, Alice Squires''<br />
----<br />
Every system has a set of properties that are largely a function of the system as a whole rather than just its constituent parts. There are dozens of these properties such as security, reliability, safety, resistance to electromagnetic interference, usability, and resilience. This Knowledge Area (KA) describes many of the most important such properties and how they are realized. The vocabulary to talk about these properties is not standard. Alternatively, they are called ''quality attributes,'' ''non-functional requirements, -ilities,'' and ''specialties.'' In this KA, the term {{Term|Specialty Engineering (glossary)|specialty engineering}} refers to the collective engineering of all quality attributes of a system. <br />
<br />
Quality attributes are often interdependent rather than orthogonal; e.g. making a system more secure may make it harder to use but also safer. Increasing system reliability often requires using more expensive parts and adding redundant components. Hence, higher reliability often means higher cost to deliver a system – another system property. However, higher reliability might mean lower maintenance cost – another system property. A systems engineer typically makes many decisions and takes many actions with regard to system properties; e.g. specifying which properties are important for a particular system, stating how those properties will be measured, trading off conflicting properties, and verifying that a system has the specified properties. Barry Boehm (2016), as the lead for a project of the [https://sercuarc.org Systems Engineering Research Center], introduced an ontology to describe system quality attributes as a way of enabling smarter tradeoffs between them and understanding the impact of those trades on cost. Also, see the article on [[Quality Management]] for more information on how these decisions and actions are managed. <br />
<br />
Many consider specialty engineering to be a sub-discipline of SE itself; e.g. they consider security engineering, safety engineering, resilience engineering, etc. to be part of SE. Others consider them to be stand-alone disciplines in their own right with close ties to SE. Either way, their mastery is important to a system engineer. This KA includes topical articles on several specialty engineering disciplines. Some articles will treat the topic of the article as a sub-discipline of SE itself; others will treat it as a closely related but separate discipline. This disparity reflects both the diversity of opinions on this matter and the fact that SEBoK articles are written by a wide array of authors. <br />
<br />
==Topics==<br />
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs, in turn, are divided into topics. This KA contains articles on the following topics, shown in alphabetical order: <br />
*[[Human Systems Integration]]<br />
*[[Manufacturability and Producibility]]<br />
*[[System Affordability]]<br />
*[[System Hardware Assurance]]<br />
*[[System Reliability, Availability, and Maintainability]]<br />
*[[System Resilience]]<br />
*[[System Resistance to Electromagnetic Interference]]<br />
*[[System Safety]]<br />
*[[System Security]]<br />
Over time, this KA will expand to add topical articles about other quality attributes.<br />
<br />
==Specialty Requirements==<br />
The systems engineering team must ensure that requirements about quality attributes (also called specialty requirements) are properly reviewed with regard to their impact on life cycle costs, development schedule, technical performance, and operational utility. For example, security requirements can impact operator workstations, electromagnetic interference requirements can impact the signal in the interfaces between subsystems, and mass-volume requirements may preclude the use of certain materials to reduce subsystem weight. <br />
<br />
Engineering specialists audit the evolving design and resulting configuration items to ensure that the overall system performance also satisfies the specialty requirements. Including appropriate specialty engineers within each systems engineering team ensures that all specialty requirements are identified and balanced throughout the development cycle.<br />
<br />
== Integration of Specialty Engineering ==<br />
Integration of specialty engineering into a project or program is, or should be, a major objective of systems engineering management. (Endler 2016, Kossiakoff et al. 2020) With properly implemented procedures, the rigor of the systems engineering process ensures participation of the specialty disciplines at key points in the technical decision-making process. Special emphasis on integration is mandatory because a given design could in fact be accomplished without consideration of these specialty disciplines, leading to the possibility of system ineffectiveness or failure when an unexamined situation occurs in the operational environment.<br />
<br />
For example, human factors considerations can contribute to reduced workloads and therefore lower error rates by operators in aircraft cockpits, at air-traffic consoles, or in nuclear reactor stations. Similarly, mean-time-to-repair features can significantly increase overall system availability in challenging physical environments, such as mid-ocean or outer space or in safety critical environments such as hospital intensive care units or in traffic control systems in city centers. Specialty engineering requirements are often manifest as constraints on the overall system design space. The role of systems engineering is to balance these constraints with other functionality in order to harmonize total system performance. The end goal is to produce a system that provides utility and effectiveness to the customer at an affordable price.<br />
<br />
As depicted in Figure 1, systems engineering plays a leadership role in integrating traditional disciplines, specialty disciplines, and unique system product demands to define the system design. Relationships for this integration process are represented as interactions among three filters. <br />
<br />
The first filter is a conceptual analysis that leverages traditional design consideration (structural, electronics, aerodynamics, mechanical, thermodynamics, etc.). The second filter evaluates the conceptual approach using specialty disciplines, such as safety, affordability, quality assurance, human factors, reliability and maintainability, producibility, packaging, test, logistics, and others, to further requirements development. Design alternatives that pass through these two processes go through a third filter that incorporates facility design, equipment design, procedural data, computer programs, and personnel to develop the final requirements for design selection and further detailed development.<br />
<br />
[[File:Fig._1_Integration_Process_for_Specialty_Engineering.png|thumb|center|800px|'''Figure 1. Integration Process for Specialty Engineering (USAF 2000).''' Released by the U.S. Air Force.]]<br />
<br />
==References== <br />
===Works Cited===<br />
Boehm, B. 2016. ''System Qualities Ontology, Tradespace, and Affordability (SQOTA) Project - Phase 4.'' Systems Engineering Research Center: Stevens Institute of Technology. February 2016. SERC-2016-TR-101.Accessed on March 3, 2021. Available at https://www.archive.sercuarc.org/wp-content/uploads/2014/05/SERC-2016-TR-101-Phase-4_RT-137.pdf.<br />
<br />
Endler, D. 2016. ''"Integration of Specialty Engineering Activities."'' Proceedings of the 26th Annual International Council on Systems Engineering (INCOSE) International Symposium, July 18-21, 2016, Edinburgh, Scotland, UK.<br />
<br />
Kossiakoff, A., W.N. Sweet, S.J. Seymour, and S.M. Biemerl. 2020. ''Systems Engineering Principles and Practice'', Third Edition. John Wiley & Sons, Inc: Hoboken, NJ, USA. <br />
<br />
USAF. 2000. ''[[Guidelines for Successful Acquisition and Management of Software-Intensive Systems]]: Weapon Systems Command and Control Systems Management Information Systems'', version 3.0. Hill AFB: Department of the Air Force Software Technology Support Center. May 2000. Accessed on March 3, 2021. Available at https://onlinelibrary.wiley.com/doi/abs/10.1002/j.2334-5837.1999.tb00315.x.<br />
<br />
===Primary References===<br />
USAF. 2000. ''[[Guidelines for Successful Acquisition and Management of Software-Intensive Systems]]: Weapon Systems Command and Control Systems Management Information Systems'', version 3.0. Hill AFB: Department of the Air Force Software Technology Support Center. May 2000. Accessed on March 3, 2021. Available at https://onlinelibrary.wiley.com/doi/abs/10.1002/j.2334-5837.1999.tb00315.x.<br />
<br />
===Additional References===<br />
None.<br />
<br />
----<br />
<center>[[Systems Engineering and Enterprise IT|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Human Systems Integration|Next Article >]]</center><br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center><br />
<br />
[[Category: Part 6]]<br />
[[Category:Knowledge Area]]<br />
[[Category:Systems Engineering and Quality Attributes]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Enterprise_IT&diff=65027
Systems Engineering and Enterprise IT
2022-05-18T13:06:43Z
<p>Mhaas: </p>
<hr />
<div><br />
----<br />
'''''Lead Author:''''' ''NAME'', '''''Contributing Authors:'''''Name, Name<br />
----<br />
Intro Paragraph<br />
<br />
==Header==<br />
<br />
==References==<br />
<br />
===Works Cited===<br />
None. <br />
<br />
===Primary References===<br />
<br />
None.<br />
<br />
===Additional References===<br />
None.<br />
<br />
----<br />
<center>[[ Systems Engineering and Economics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Quality Attributes|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Enterprise_IT&diff=65026
Systems Engineering and Enterprise IT
2022-05-18T13:06:22Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div><br />
----<br />
'''''Lead Author:''''' ''NAME'', '''''Contributing Authors:'''''Name, Name<br />
----<br />
Intro Paragraph<br />
<br />
==Header==<br />
<br />
==References==<br />
<br />
===Works Cited===<br />
None. <br />
<br />
===Primary References===<br />
<br />
None.<br />
<br />
===Additional References===<br />
None.<br />
<br />
----<br />
<center>[[ Systems Engineering and Economics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Enterprise IT|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Economics&diff=65025
Systems Engineering and Economics
2022-05-18T13:05:48Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div><br />
----<br />
'''''Lead Author:''''' ''NAME'', '''''Contributing Authors:'''''Name, Name<br />
----<br />
Intro Paragraph<br />
<br />
==Header==<br />
<br />
==References==<br />
<br />
===Works Cited===<br />
None. <br />
<br />
===Primary References===<br />
<br />
None.<br />
<br />
===Additional References===<br />
None.<br />
<br />
----<br />
<center>[[Systems Engineering and Civil Engineering|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Enterprise IT|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Civil_Engineering&diff=65024
Systems Engineering and Civil Engineering
2022-05-18T12:58:18Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div><br />
----<br />
'''''Lead Author:''''' ''NAME'', '''''Contributing Authors:'''''Name, Name<br />
----<br />
Intro Paragraph<br />
<br />
==Header==<br />
<br />
==References==<br />
<br />
===Works Cited===<br />
None. <br />
<br />
===Primary References===<br />
<br />
None.<br />
<br />
===Additional References===<br />
None.<br />
<br />
----<br />
<center>[[Systems Engineering and Mechanical Engineering|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Economics|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Mechanical_Engineering&diff=65023
Systems Engineering and Mechanical Engineering
2022-05-18T12:57:09Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div><br />
----<br />
'''''Lead Authors:''''' Leigh McCue and John Shortle, '''''Contributing Author:''''' Art Pyster<br />
----<br />
This treatment opens with a brief overview of subdisciplines of mechanical engineering. The interested reader seeking a more thorough study on Mechanical Engineering (ME) is referred to Sagdeh and Worek (2017) and other references identified below. As stated by Hibbeler (2015), “Mechanics is a branch of the physical sciences that is concerned with the state of rest or motion of bodies that are subjected to the action of forces. In general, this subject can be subdivided into three branches: rigid-body mechanics, deformable-body mechanics, and fluid mechanics.” It is with those branches that this summary begins, before delving into thermodynamics, controls, and mechanical engineering design and the relationship between SE and ME.<br />
<br />
==Rigid-Body Mechanics and Deformable Body Mechanics==<br />
Mechanical engineering and civil engineering structural analysis bear much in common, as both fundamentally seek to create structures to satisfy a design need. While the bridge designer may prioritize material selections that hold up under constant use and varying weather conditions, the race car designer may prioritize light weight while maintaining crash worthiness. In the process of structural analysis, one applies Newton’s laws to analyze loads at joints and calculates internal forces, shear, and moment on structural elements. By understanding the loads a joint or structural element must withstand, one can select materials with appropriate properties to prevent failure. A structural element that changes its shape under load is known as a deformable body, whereas a body for which the distances between points on the body remain constant regardless of loading is known as a rigid body. The study of static structures, solid mechanics, and materials are typically foundational in a mechanical engineering undergraduate curriculum (e.g. (Hibbeler 2015), (Philpot and Thomas 2020), and (Callister and Rethwich 2019)).<br />
<br />
==Dynamics ==<br />
A subset of mechanics is dynamics. Eloquently summarized by Greenwood (1965), “[t]he science of mechanics is concerned with the study of the interactions of material bodies. Dynamics is that branch of mechanics which consists of the study of the motions of interacting bodies and the description of these motions in terms of postulated laws.” In static rigid-body mechanics, with structures that are not accelerating, we write Newton’s second law as ΣF=0. In dynamics we utilize ΣF=''m''a and leverage conservation of energy and momentum in analyzing systems. Simple dynamics problems typically involve the swinging of a pendulum or a spring-mass-damper system and evolve in complexity to modern suspension systems, orbital dynamics, and the multi-body challenges one might see when landing a rescue helicopter on the deck of a Coast Guard vessel.<br />
<br />
==Fluid Mechanics==<br />
Fluid mechanics includes experimental, computational, and analytical modeling of forces on a body moving in a liquid. Models of fluid dynamics often utilize the [https://en.wikipedia.org/wiki/Navier–Stokes_equations Navier-Stokes equations], a collection of partial differential equations arising from conservation of mass and momentum. For inviscid flows, the Navier-Stokes equations can be simplified to the [https://en.wikipedia.org/wiki/Euler_equations_(fluid_dynamics) Euler equations]. The Euler equations can be further simplified to [https://en.wikipedia.org/wiki/Bernoulli%27s_principle Bernoulli’s equation] in the special case of steady, incompressible, irrotational flow along a streamline. Common dimensionless parameters to characterize a flow include [https://en.wikipedia.org/wiki/Reynolds_number Reynolds number], Froude number, and Mach number. Reynolds number is a measure of the inertial forces to viscous forces, [https://en.wikipedia.org/wiki/Froude_number Froude number] characterizes the ratio of inertial forces to gravitational forces, and [https://en.wikipedia.org/wiki/Mach_number Mach number] provides a ratio of flow speed to the speed of sound. A comprehensive introductory text on fluid mechanics is Batchelor (2000).<br />
<br />
==Thermodynamics==<br />
Mechanical engineering thermodynamics involves products where heat is a primary consideration in the generation or transfer of energy – examples include engines, refrigeration systems, and nuclear reactors. At a broad level, the study of thermodynamics is captured by the following laws:<br />
<br />
* ''Zeroth law: '' “[W]hen two bodies are in thermal equilibrium with a third body, they are in thermal equilibrium with one another.” (Moran and Shapiro 1998).<br />
* ''First law: '' “[T]he value of the net work done by or on a closed system undergoing an adiabatic process between two given states depends solely on the end states and not on the details of the adiabatic process.” (Moran and Shapiro 1998). In short, energy can be neither created nor destroyed.<br />
* ''Second law: '' “It is impossible for any system to operate in such a way that the sole result would be an energy transfer by heat from a cooler to a hotter body.” (Moran and Shapiro 1998). Notably, the first and second laws together are what render a perpetual motion machine physically impossible.<br />
* ''Third law: '' “[T]he entropy of a pure crystalline substance is zero at the absolute zero of temperature...” (Moran and Shapiro 1998).<br />
<br />
Relating thermodynamics to the mechanics topics described above, in a comprehensive summary paper, Graham Baker quotes Clifford Truesdell stating “As mechanics is the science of motions and forces, so thermodynamics is the science of forces and entropy.” (Baker 2005).<br />
<br />
==Controls==<br />
Controls refers to "the process of causing a system variable to conform to some desired value, called a reference value.” (Franklin et al. 1994) In application, this requires assimilating knowledge of the above disciplines to devise a system to achieve a desired outcome; e.g. measuring room temperature and using that as feedback to control an HVAC system, or measuring orientation and angular velocity to ideally time the firing of a spacecraft thruster to achieve a target orbit.<br />
<br />
==Design==<br />
In design, one combines knowledge of these specific fields to develop products of need by a customer or society. The Accreditation Board for Engineering and Technology (ABET) definition of design is agnostic to engineering discipline; specifically, they state “Engineering design is a process of devising a system, component, or process to meet desired needs and specifications within constraints. It is an iterative, creative, decision-making process in which the basic sciences, mathematics, and engineering sciences are applied to convert resources into solutions. Engineering design involves identifying opportunities, developing requirements, performing analysis and synthesis, generating multiple solutions, evaluating solutions against requirements, considering risks, and making trade-offs, for the purpose of obtaining a high-quality solution under the given circumstances." (ABET n.d.) In the design process, mechanical engineers use their knowledge of these disciplines to address societal needs. Furthermore, a key aspect of mechanical engineering design is the decision-making process. As such, decision theory is a key component to the study of design. (Tebay et al. 1984). Approaches to mechanical engineering design vary from waterfall (sequential) style to agile (parallel) methods, with waterfall methods more likely to be governed by a design spiral leading to a single point design whereas agile methods are iterative. Set-based design has become increasingly common in recent years, gaining benefit from increased flexibility by pursuing a broad design space, eliminating options over time as data and validation of underlying assumptions warrant. (Scaled Agile n.d.)<br />
<br />
==Application to Related Subdisciplines==<br />
These fundamental knowledge areas provide core skills for deeper knowledge in numerous subdisciplines, often taught as standalone multi-disciplinary fields. For example:<br />
<br />
===Aerospace Engineering===<br />
Aircraft and spacecraft require command of each of these core areas. For example fluid-dynamics permits understanding the forces of lift and draft on a body. Thermodynamics allows modeling thermal effects on engines, craft operating at high speeds, or subject to large thermal load fluctuations in space. Application of knowledge of dynamics and control allows engineers to develop safe, operable vehicles with performance traits tailored to design need. Expertise in mechanics and materials allows one to develop light weight structures. And ultimately, the design process enables the development and refinement of prototype and production vehicles. Aircraft provide numerous examples of the ties between mechanical engineering and systems engineering. For example, a Boeing 747 has approximately 6 million parts, provided by over 550 suppliers (Boeing 2013), relying on supply chain management. Furthermore, an airline fleet becomes a system of aircraft with the air traffic network constituting a system of systems.<br />
<br />
===Naval Engineering===<br />
Naval engineers function in many ways as systems engineers. Recognizing, for example, the wide range of engineering complexities involved in designing, building, and operating an aircraft carrier – from hull, mechanical, and electrical system design, to hydrodynamics and maneuvering, to integrated warfare systems, to aircraft operations, to hotel services for crew, the modern naval combatant is a highly complicated system of systems. A representative reference is provided in Lamb (2003). <br />
<br />
==Codes and Standards==<br />
The American Society of Mechanical Engineers (ASME) has been involved in the development of codes and standards for mechanical engineering systems since its first standard, “Code for the Conduct of Trials of Steam Boilers” released in 1884. (ASME n.d.a) As a testament to the complexity of mechanical engineering systems, in the present day, ASME standards are used in more than 100 countries and cover topics as diverse as elevators to nuclear plants with guidance under development for additive manufacturing and robotics, amongst other fields. (ASME n.d.)<br />
<br />
==Relationship between Mechanical and Systems Engineering==<br />
ME emphasizes design, development, and research on dynamic systems, be it turbines, prosthetics, or autonomous vehicles. Mechanical engineering products often form the building blocks for systems of systems; for example, a materials scientist designs the fan blade that goes into another mechanical engineer’s turbine engine design which resides on an aerospace engineer designed fighter jet, operating off an aircraft carrier designed by naval and systems engineers. One of the best examples of the relationship between ME and SE is with regard to human systems integration, in which multidisciplinary teams assess topics such as ergonomics, health, safety, user interface design, and human performance in designing mechanical systems. Systems engineers often lead such assessments. A comprehensive reference on human systems integration is Booher (2003).<br />
<br />
Relatively junior mechanical engineers often focus heavily on the individual subdisciplines of ME, such as those described earlier in this article. They might, for example, conduct a structural analysis of an individual physical assembly. As mechanical engineers gain experience and take on more senior roles, they often become concerned with the larger context in which mechanical components fit and hence take on many of the roles that systems engineers perform but with a focus on the mechanical subsystems. This becomes quite evident when looking at advertisements for senior mechanical engineers. For example, in a May 2022 listing of 20 senior mechanical engineer positions on one online job site, responsibilities included such systems engineering activities as reviewing mechanical documents for areas of conflict with all disciplines, resolving discrepancies between the employer and customer requirements, working with external partners and projects to ensure interoperability of internal and external components, driving internal development methodology, owning the full life cycle for parts, and managing the quality of deliverables while coordinating with other project disciplines.<br />
<br />
==References==<br />
===Works Cited===<br />
ABET. n.d. “Criteria for Accrediting Engineering Programs, 2020 – 2021,” Accreditation Board for Engineering and Technology. Accessed on May 9, 2022. Available: https://www.abet.org/accreditation/accreditation-criteria/criteria-for-accrediting-engineering-programs-2020-2021/. <br />
<br />
ASME. n.d. “About ASME Standards and Certification”, Accessed on May 9, 2022. Available: https://www.asme.org/codes-standards/about-standards. <br />
<br />
ASME. n.d.a. “History of ASME Standards", American Society of Mechanical Engineers. Accessed on May 9, 2022. Available: https://www.asme.org/codes-standards/about-standards/history-of-asme-standards.<br />
<br />
Baker, G. 2005. “Thermodynamics in solid mechanics: a commentary,” Philosophical Transactions of the Royal Society A. Accessed on May 9, 2022. Available: https://doi.org/10.1098/rsta.2005.1669<br />
<br />
Batchelor, G.K. 2000. ''An Introduction to Fluid Dynamics'', Cambridge University Press.<br />
<br />
Boeing. 2013. “Boeing Celebrates Delivery of 50th 747-8”. Ma7 29, 2013. Accessed on May 9, 2022. Available: https://boeing.mediaroom.com/2013-05-29-Boeing-Celebrates-Delivery-of-50th-747-8.<br />
<br />
Booher, H.R. (ed.). 2003. ''Handbook of Human Systems Integration'', Hoboken:Wiley.<br />
<br />
Callister Jr., W.D. and D.G. Rethwisch. 2015. ''Fundamentals of Materials Science and Engineering: An Integrated Approach'', 5th Edition, Hoboken: Wiley.<br />
<br />
Franklin, G.F., J. D. Powell, and A. Emami-Naeini. 1994. ''Feedback Control of Dynamic Systems,'' 3rd Edition, Addison Wesley.<br />
<br />
Greenwood, D.T. 1965. ''Principles of Dynamics'', Prentice Hall.<br />
<br />
Hibbeler, R.C. 2015. ''Engineering Mechanics: Statics,'' 14th Edition, Pearson.<br />
<br />
Lamb, T. (ed.) 2003. ''Ship Design and Construction'', The Society of Naval Architects and Marine Engineers.<br />
<br />
Philpot, T.A. and J.S. Thomas. 2020. ''Mechanics of Materials: An Integrated Learning System'', 5th Edition, Hoboken: Wiley.<br />
<br />
Moran, M.J. and H.N. Shapiro. 1998. ''Fundamentals of Engineering Thermodynamics'', 3rd Edition, Hoboken: Wiley. <br />
<br />
Sadegh, A. and W. Worek. 2017. ''Mark’s Standard Handbook for Mechanical Engineers'', 12th Edition, McGraw Hill.<br />
<br />
Scaled Agile. n.d. “Set-Based Design”. Accessed on May 9, 2022. Available: https://www.scaledagileframework.com/set-based-design/.<br />
<br />
Tebay, R., J. Atherton, and S.H. Wearne. 1984. “Mechanical engineering design decisions: instances of practice compared with theory,” Institution of Mechanical Engineers, Part B: Journal of Engineering Manufacture, Sage Journals.<br />
<br />
===Primary References===<br />
Batchelor, G.K. 2000. ''[[An Introduction to Fluid Dynamics]]'', Cambridge University Press.<br />
<br />
Booher, H.R. (ed.). 2003. ''[[Handbook of Human Systems Integration]]'', Hoboken:Wiley.<br />
<br />
Callister Jr., W.D. and D.G. Rethwisch. 2015. ''[[Fundamentals of Materials Science and Engineering: An Integrated Approach]]'', 5th Edition, Hoboken: Wiley.<br />
<br />
Franklin, G.F., J. D. Powell, and A. Emami-Naeini. 1994. ''[[Feedback Control of Dynamic Systems]]'', 3rd Edition, Addison Wesley.<br />
<br />
Greenwood, Donald T. ''[[Principles of Dynamics]]'', Prentice Hall, 1965.<br />
<br />
Hibbeler, R.C. 2015. ''[[Engineering Mechanics: Statics]]'', 14th Edition, Pearson.<br />
<br />
Moran, M.J. and H.N. Shapiro. 1998. ''[[Fundamentals of Engineering Thermodynamics]]'', 3rd Edition, Hoboken: Wiley.<br />
<br />
Philpot, T.A. and J.S. Thomas. 2020. ''[[Mechanics of Materials: An Integrated Learning System]]'', 5th Edition, Hoboken: Wiley.<br />
<br />
Sadegh, A. and W. Worek. 2017. ''[[Mark’s Standard Handbook for Mechanical Engineers]]'', 12th Edition, McGraw Hill.<br />
<br />
===Additional References===<br />
CFD. n.d. CFD Online Accessed on May 9, 2022. Available: https://www.cfd-online.com/Wiki/Main_Page <br />
<br />
<br />
----<br />
<center>[[Systems Engineering and Electrical Engineering|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Civil Engineering|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Electrical_Engineering&diff=65022
Systems Engineering and Electrical Engineering
2022-05-18T12:55:01Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div><br />
----<br />
'''''Lead Author:''''' ''NAME'', '''''Contributing Authors:'''''Name, Name<br />
----<br />
Intro Paragraph<br />
<br />
==Header==<br />
<br />
==References==<br />
<br />
===Works Cited===<br />
None. <br />
<br />
===Primary References===<br />
<br />
None.<br />
<br />
===Additional References===<br />
None.<br />
<br />
----<br />
<center>[[Systems Engineering and Aerospace Engineering|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Mechanical Engineering|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Aerospace_Engineering&diff=65021
Systems Engineering and Aerospace Engineering
2022-05-18T12:54:14Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div><br />
----<br />
'''''Lead Author:''''' ''NAME'', '''''Contributing Authors:'''''Name, Name<br />
----<br />
Intro Paragraph<br />
<br />
==Header==<br />
<br />
==References==<br />
<br />
===Works Cited===<br />
None. <br />
<br />
===Primary References===<br />
<br />
None.<br />
<br />
===Additional References===<br />
None.<br />
<br />
----<br />
<center>[[Software Engineering Features - Models, Methods, Tools, Standards, and Metrics|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Electrical Engineering|Next Article >]]</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Software_Engineering_Features_-_Models,_Methods,_Tools,_Standards,_and_Metrics&diff=65020
Software Engineering Features - Models, Methods, Tools, Standards, and Metrics
2022-05-18T12:52:54Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div>----<br />
'''''Lead Author:''''' ''Tom Hilburn''<br />
----<br />
In recent decades, software has become ubiquitous. Almost all modern engineered systems include significant software subsystems; this includes systems in the transportation, finance, education, healthcare, legal, military, and business sectors. Along with the increase in software utility, capability, cost, and size there has been a corresponding growth in methods, models, tools, metrics and standards, which support software engineering.<br />
<br />
Chapter 10 of the SWEBOK discusses modeling principles and types, and the methods and tools that are used to develop, analyze, implement, and verify the models. The other SWEBOK chapters on the software development phases (e.g., Software Design) discuss methods and tools specific to the phase. Table 1 identifies software engineering features for different life-cycle phases. The table is not meant to be complete; it simply provides examples. In Part 2 of the SEBoK there is a [[Representing Systems with Models|discussion of models]] and the following is one of the definitions offered: “an abstraction of a system, aimed at understanding, communicating, explaining, or designing aspects of interest of that system” (Dori 2002). <br />
<br />
For the purposes of Table 1 the definition of a model is extended to some aspect of the software system or its development. As an example, “Project Plan” is listed as a model in the Software Management area. The idea is that the Project Plan provides a model of how the project is going to be carried out: the project team organization, the process to be used, the work to be done, the project schedule, and the resources needed.<br />
<br />
<div style="text-align: center;"><br />
<blockquote>'''Table 1: SWE Features''' (SEBoK Original)<br />
</blockquote><br />
</div><br />
{| align="center"<br />
|-<br />
!Life-Cycle Activity<br />
!Models<br />
!Methods & Tools<br />
!Standards<br />
|-<br />
| <br />
Software Management<br />
| <br />
*Life-Cycle Process Model<br />
*Work Breakdown Structure<br />
*Constructive Cost Model (COCOMO)<br />
*Project Plan<br />
*Configuration Management (CM) Plan<br />
*Risk Management Plan<br />
|<br />
*Effort, Schedule and Cost Estimation<br />
*Risk Analysis<br />
*Data Collection<br />
*Project Tracking<br />
*CM Management<br />
*Iterative/Incremental Development<br />
*Agile Development<br />
|<br />
*<nowiki>[</nowiki>IEEE 828<nowiki>]</nowiki> <br />
*<nowiki>[</nowiki>IEEE 1058<nowiki>]</nowiki><br />
*<nowiki>[</nowiki>IEEE 1540<nowiki>]</nowiki><br />
*<nowiki>[</nowiki>IEEE 12207<nowiki>]</nowiki><br />
|-<br />
|<br />
Software Requirements<br />
| <br />
*Functional Model<br />
*User Class Model<br />
*Data Flow Diagram<br />
*Object Model<br />
*Formal Model<br />
*User Stories<br />
|<br />
*Requirements Elicitation<br />
*Prototyping<br />
*Structural Analysis<br />
*Data-Oriented Analysis<br />
*Object-Oriented Analysis<br />
*Object Modeling Language (OML)<br />
*Formal Methods<br />
*Requirements Specification<br />
*Requirements Inspection<br />
|<br />
*<nowiki>[</nowiki>IEEE 830<nowiki>]</nowiki><br />
*<nowiki>[</nowiki>IEEE 1012<nowiki>]</nowiki><br />
*<nowiki>[</nowiki>IEEE 12207<nowiki>]</nowiki><br />
|-<br />
|<br />
Software Design<br />
|<br />
*Architectural Model<br />
*Structure Diagram<br />
*Object Diagram<br />
*Class Specification<br />
*Data Model<br />
|<br />
*Structured Design<br />
*Object-Oriented Design<br />
*OML <br />
*Modular Design<br />
*Integrated Development Environment (IDE)<br />
*Database Management System (DBMS)<br />
*Design Review<br />
*Refinement<br />
|<br />
*<nowiki>[</nowiki>IEEE 1012<nowiki>]</nowiki><br />
*<nowiki>[</nowiki>IEEE 1016<nowiki>]</nowiki><br />
*<nowiki>[</nowiki>IEEE 12207<nowiki>]</nowiki><br />
*<nowiki>[</nowiki>IEEE 42010<nowiki>]</nowiki><br />
|-<br />
|<br />
Software Construction<br />
|<br />
*Detail Design Document<br />
*Pseudocode<br />
*Flow Chart<br />
*Program Code<br />
*Unit Test Plan<br />
*Integration Test Plan<br />
|<br />
*Detailed Design<br />
*Functional Programming<br />
*Object-Oriented Programming<br />
*IDE<br />
*DBMS<br />
*Black Box/White Box Testing<br />
*Basic Path Testing<br />
*Unit Testing<br />
*Code Review<br />
*Proof of Correctness<br />
*Software Reuse<br />
*Integration<br />
*Integration Testing<br />
|<br />
*<nowiki>[</nowiki>IEEE 1008<nowiki>]</nowiki><br />
*<nowiki>[</nowiki>IEEE 1012<nowiki>]</nowiki><br />
*<nowiki>[</nowiki>IEEE 1016<nowiki>]</nowiki><br />
*<nowiki>[</nowiki>IEEE 12207<nowiki>]</nowiki><br />
|-<br />
|<br />
Software Testing<br />
|<br />
*System Test Plan<br />
*Reliability Model<br />
*Software Maintenance Process<br />
|<br />
*Usability Testing<br />
*System Testing<br />
*Acceptance Testing<br />
*Regression Testing<br />
*Reliability Testing<br />
*Non-Functional Software Testing<br />
|<br />
*<nowiki>[</nowiki>IEEE 829<nowiki>]</nowiki><br />
*<nowiki>[</nowiki>IEEE 1012<nowiki>]</nowiki><br />
*<nowiki>[</nowiki>IEEE 12207<nowiki>]</nowiki><br />
|-<br />
|<br />
Software Maintenance<br />
|<br />
*Software Maintenance Process<br />
|<br />
*Automated Testing Tools<br />
*Maintenance Change<br />
*Impact Analysis<br />
*Inventory Analysis<br />
*Restructuring<br />
*Reverse Engineering<br />
*Re-engineering<br />
|<br />
*<nowiki>[</nowiki>IEEE 1219<nowiki>]</nowiki><br />
*<nowiki>[</nowiki>IEEE 12207<nowiki>]</nowiki><br />
*<nowiki>[</nowiki>IEEE 14764<nowiki>]</nowiki><br />
|}<br />
<br />
== Software Metric ==<br />
A software metric is a quantitative measure of the degree a software system, component, or process possesses a given attribute. Because of the abstract nature of software and special problems with software schedule, cost, and quality, data collection and the derived metrics are an essential part of software engineering. This is evidenced by the repeated reference to measurement and metrics in the SWEBOK. Table 2 describes software metrics that are collected and used in different areas of software development. As in Table 1 the list is not meant to be complete, but to illustrate the type and range of measures used in practice.<br />
<br />
<div style="text-align: center;"><br />
<blockquote>'''Table 2: Software Metrics''' <nowiki>*</nowiki> (SEBoK Original)<br />
</blockquote><br />
</div><br />
<br />
{| align="center"<br />
|-<br />
! Category<br />
! Metrics<br />
|-<br />
| <br />
Management Metrics<br />
<br />
| <br />
*Size: Lines of Code (LOC*), Thousand Lines of Code (KLOC)<br />
*Size: Function points, Feature Points<br />
*Individual Effort: Hours<br />
*Task Completion Time: Hours, Days, Weeks<br />
*Project Effort: Person-Hours<br />
*Project Duration: Months<br />
*Schedule: Earned Value<br />
*Risk Projection: Risk Description, Risk Likelihood, Risk Impact<br />
|-<br />
| <br />
Software Quality Metrics<br />
|<br />
*Defect Density - Defects/KLOC (e.g., for system test)<br />
*Defect Removal Rate – Defects Removed/Hour (for review and test)<br />
*Test Coverage<br />
*Failure Rate<br />
<br />
|-<br />
| <br />
Software Requirements Metrics<br />
|<br />
*Change requests (received, open, and closed)<br />
*Change request frequency<br />
*Effort required to implement a requirement change<br />
*Status of requirements traceability<br />
*User stories in the backlog<br />
|-<br />
| <br />
Software Design Metrics<br />
|<br />
*Cyclomatic Complexity<br />
*Weighted Methods per Class<br />
*Cohesion - Lack of Cohesion of Methods<br />
*Coupling - Coupling Between Object Classes<br />
*Inheritance - Depth of Inheritance Tree, Number of Children<br />
|-<br />
| <br />
Software Maintenance and Operation<br />
|<br />
*Mean Time Between Changes (MTBC)<br />
*Mean Time to Change (MTTC)<br />
*System Reliability<br />
*System Availability<br />
*Total Hours of Downtime<br />
<br />
|}<br />
<br />
<nowiki>*</nowiki>''Note: Even though the LOC metric is widely used, using it comes with some problems and concerns: different languages, styles, and standards can lead to different LOC counts for the same functionality; there are a variety of ways to define and count LOC– source LOC, logical LOC, with or without comment lines, etc.; and automatic code generation has reduced the effort required to produce LOC.''<br />
<br />
__NOTOC__<br />
<br />
==References==<br />
===Works Cited===<br />
Bourque, P. and R.E. Fairley (eds.). 2014. ''Guide to the Software Engineering Body of Knowledge (SWEBOK)''. Los Alamitos, CA, USA: IEEE Computer Society. Available at: http://www.Swebok.org.<br />
<br />
Dori, D. 2003. "Conceptual modeling and system architecting." ''Communications of the ACM'', 46(10), pp. 62-65.<br />
<br />
[IEEE 828] IEEE Computer Society, IEEE Standard for ''Computer Configuration Management in Systems and Software Engineering'', IEEE Std 828- 2012, 20012.<br />
<br />
[IEEE 829] IEEE Computer Society, IEEE Standard for ''Software and System Test Documentation'', IEEE Std 829- 2008, 2008.<br />
<br />
[IEEE 830] IEEE Computer Society, IEEE Standard for ''Recommended Practice for Software Requirements Specifications'', IEEE Std 830-1998, 1998.<br />
<br />
[IEEE 1008] IEEE Computer Society, IEEE Standard for ''Software Unit Testing,'' IEEE Std 1008-1987, 1987.<br />
<br />
[IEEE 1012] IEEE Computer Society, IEEE Standard for ''System and Software Verification and Validation'', IEEE Std 1012-2002, 2012.<br />
<br />
[IEEE 1016] IEEE Computer Society, IEEE Standard for ''Recommended Practice for Software Design Descriptions'', IEEE Std 1016-2002, 2002.<br />
<br />
[IEEE 1058] IEEE Computer Society, IEEE Standard for ''Software Project Plans'', IEEE Std 1058-1998, 1998.<br />
<br />
[IEEE 1219] IEEE Computer Society, IEEE Standard for ''Software Maintenance'', IEEE Std 1219-1998, 1998.<br />
<br />
[IEEE 1540] IEEE Computer Society, IEEE Standard for ''Risk Management'', IEEE Std 1540-2001, 2001.<br />
<br />
[IEEE 12207] IEEE Computer Society, IEEE Standard for ''Systems and Software Engineering —Software Life Cycle Processes'', IEEE Std 12207-2008, 2008.<br />
<br />
[IEEE 14764] IEEE Computer Society, IEEE Standard for ''Software Engineering - Software Life Cycle Processes - Maintenance''. IEEE Std 14764-2006, 2006.<br />
<br />
[IEEE 42010] IEEE Computer Society, IEEE Standard for ''Systems and Software Engineering — Architecture Description'', IEEE Std 42010-2011, 2011.<br />
<br />
===Primary References===<br />
<br />
None.<br />
<br />
===Additional References===<br />
Chidamber, S.R., C.F. Kemerer. 1994. “A Metrics Suite for Object Oriented Design”, ''IEEE Transactions on Software Engineering''. Vol. 20, No. 6. June 1994.<br />
<br />
Kan, Stephen H. 2003. ''Metrics and Models in Software Quality Engineering'', 2nd edition. Reading, Massachusetts, USA: Addison-Wesley.<br />
<br />
Li, M. and Smidts, C. 2003. “A ranking of software engineering measures based on expert opinion.” ''IEEE Transactions on Software Engineering''. September 2003.<br />
<br />
McConnell, Steve. 2009. ''Code Complete'', 2nd Ed. Microsoft Press.<br />
<br />
Moore, James. 1997. ''Software Engineering Standards: A User's Road Map''. Hoboken, NJ, USA: Wiley-IEEE Computer Society Press.<br />
<br />
Sommerville, I. 2010. ''Software Engineering''. 9th Ed. Boston, MA, USA: Addison Wesley.<br />
<br />
----<br />
<br />
<center>[[Key Points a Systems Engineer Needs to Know about Software Engineering|< Previous Article]] | [[Systems Engineering and Software Engineering|Parent Article]] | [[Systems Engineering and Aerospace Engineering|Next Article >]]</center><br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center><br />
<br />
[[Category: Part 6]][[Category: Topic]][[Category:Systems Engineering and Software Engineering]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_and_Industrial_Engineering&diff=65019
Systems Engineering and Industrial Engineering
2022-05-18T12:49:49Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div>----<br />
'''''Lead Author:''''' ''Gregory S. Parnell'', '''''Contributing Authors:''''' ''C. Robert Kenley, Eric Specking, Ed Pohl''<br />
----Systems Engineering (SE) overlaps with many fields, such as Industrial Engineering (IE), Engineering Management, Operations Research, Project Management, and Design Engineering. In fact, the main Industrial Engineering body of knowledge, called the Industrial and Systems Engineering Body of Knowledge (ISEBoK) (IISE 2021), includes the word "systems" in its title and includes a section on systems design and engineering, which references the SEBoK. This article describes the similarities and differences between SE and IE based upon their respective standards, handbooks, and bodies of knowledge. Based on this assessment, this article describes potential roles that systems engineers and industrial engineers perform during a system’s life cycle. <br />
<br />
= Introduction =<br />
When systems engineers and industrial engineers are in the same organization, they have different roles and responsibilities. While job titles vary by organization, many organizations have individuals that perform both SE and IE activities. This article tries to help systems engineers and industrial engineers better understand the different perspectives of the fields and the knowledge needed to meet the needs of their organizations and customers. The article compares the use of international standards and the contents of the bodies of knowledge for SE and IE. <br />
<br />
= Systems Engineering =<br />
The International Council on Systems Engineering (INCOSE) is a “not-for-profit membership organization founded to develop and disseminate the interdisciplinary principles and practices that enable the realization of successful systems.” INCOSE defines systems engineering as<blockquote>''a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods. (INCOSE 2021)''</blockquote>Here, the terms “engineering” and “engineered” are used in their widest sense: “the action of working artfully to bring something about.” “Engineered systems” may be composed of any or all of people, products, services, information, processes, and natural elements.<br />
<br />
INCOSE aligns its SE Handbook with ISO/IEC/IEEE 15288, System Life Cycle Processes, which focuses on processes. SEBoK Part 3 [[Systems Engineering and Management]], which addresses the major SE technical and management processes, is also organized around 15288 process areas. In this view, SE is process oriented. Each edition of the SE Handbook aligns to an ISO/IEC/IEEE 15288 edition. Figure 1 shows the 15288 processes and how they align with the SE Handbook and SEBoK topic areas. Later in this article, these SEBoK topics and knowledge areas are compared with the knowledge areas of IE. The knowledge areas in Figure 1 align with the system life cycle if started at the top of the first column and traversed to the bottom, continued at the bottom of the second column and traversed to the top, and then continued at the bottom of the third column and traversed to the top.<br />
<br />
[[File:Mapping_of_tech_topics_SEBoK_with_ISO_IEC_15288techPro_060612.jpg|thumb|700px|center|<center>'''Figure 1. Technical Topics of SEBoK Knowledge Areas Mapped to ISO/IEC/IEEE 15288 Technical Processes.''' (SEBoK 2022)</center>]]<br />
<br />
= Industrial Engineering =<br />
The Institute of Industrial and Systems Engineers (IISE) states that it is “the only international, non-profit, professional society dedicated to advancing the technical and managerial excellence of industrial engineers.” (IISE 2021). IISE started in 1948 as the American Institute of Industrial Engineers. In 1981, the organization was renamed the Institute of Industrial Engineers to reflect its growing international membership. In 2016, the membership voted to change the name to the Institute of Industrial and Systems Engineers. This addition reflects a vote by its membership and aligns with the “changing scope of the profession that, while keeping its industrial base, has seen more industrial and systems engineers working with large scale integrated systems in a variety of sectors”. <br />
<br />
At the turn of this century, industrial engineering was well reflected in two prominent publications: ''Handbook of Industrial Engineering'' (Salvendy 2001) and the fifth edition of ''Maynard's Industrial Engineering Handbook'' (Zandin 2001). Salvendy (2001) stated that industrial engineers are trained to design and analyze the components of which man-machine systems are composed. They bring together individual elements that are designed via other engineering disciplines and properly synergize these subsystems together with the people components for a completely integrated man-machine system. Industrial engineers are focused on the improvement of any system that is being designed or evaluated. They make individual human tasks more productive and efficient by optimizing flow, eliminating unnecessary motions, utilizing alternate materials to improve manufacturing, improving the flow of product through processes, and optimizing the configuration of workspaces. Fundamentally, the industrial engineer is charged with reducing costs and increasing profitability through ensuring the efficient use of human, material, physical, and/or financial resources. <br />
<br />
The view of IE has evolved over the last two decades. IISE developed the IISE Body of Knowledge in 2021 (IISE 2021). The sixth edition of ''Maynard's Industrial Engineering Handbook'' (Zandin 2022) is expected to be published in 2022. The IISEBoK has 14 knowledge areas, as shown in Figure 2. The first 13 knowledge areas identify the Industrial Engineering knowledge. The fourteenth is Systems Design and Engineering, which references the SEBoK. The IISEBoK provides a short description of each knowledge area, a detailed outline of knowledge area topics, and a list of references. The IISEBoK does not use standards as its foundation. In fact, the Standard Practice for Systems Safety (MIL-STD-0-882D) is the only standard cited in the reference section. IISE does not currently have a handbook developed by or for the Institute, although Zandin (2022) is expected to align with the IISEBoK.<br />
<br />
[[File:IISE_BoK.jpeg|thumb|600px|center|''Figure 2. Industrial and Systems Engineering Knowledge Areas'' (IISE 2022, Used with Permission) [https://www.iise.org/BodyofKnowledge]]]<br />
<br />
The 14 topic areas included in the IISEBoK could be tied to many international standards even though the IISEBoK does not use standards as its foundation or provide references to standards in most of its topic areas.<br />
<br />
= Venn Diagram Comparison =<br />
This section compares the two bodies of knowledge. Figure 3 is a Venn Diagram that identifies knowledge areas that are usually performed by systems engineers, ones usually performed by industrial engineers, and ones that are used by both disciplines.<br />
<br />
[[File:SE&IE_Venn.png|thumb|center|700px|''Figure 3. Venn Diagram'' (SEBoK Original]]<br />
<br />
There are 11 primarily SE knowledge areas, 7 primarily IE knowledge areas, and 12 overlapping knowledge areas. Table 1 provides some illustrative examples of the differences in SE and IE focus in the overlapping knowledge areas.<br />
<br />
{| class="wikitable"<br />
|+Table 1. Illustrative Examples of Differences in SE and IE Focus<br />
|-<br />
|Knowledge Area<br />
|Systems Engineering Focus<br />
|Industrial Engineering Focus<br />
|-<br />
|2. Operations Research (OR) and Analysis<br />
|OR and analysis is used in systems analysis to assess system performance and to evaluate system designs (Levis and Wagenhals 2000; Wagenhals, Shin, Kim, and Levis 2000; Wagenhals, Haider, and Levis 2003; Raz, Kenley, and DeLaurentis 2018)<br />
|OR and analysis is used to optimize operations, maintenance, and logistics. OR is also used to evaluate and optimize manufacturing systems. <br />
|-<br />
|5. Quality & Reliability Engineering<br />
|Quality and reliability requirements are treated as system-wide performance requirements (Buede and Miller 2016: 157-159; Wymore 1993: 401) that are assessed at the systems level. One example is availability, A<sub>0</sub>, which measures the degree to which a system is either operating or can operate at any time when used in its typical operational and support environment. (DA PAM 70-3 2008: 87)<br />
|Quality and reliability are used to evaluate and improve the manufacturing process of goods and services. Reliability is also used to evaluate and improve system operations.<br />
|-<br />
|6. Ergonomics and Human Factors<br />
|Ergonomics and human factors are considerations in assessing the potential usability of a system for end-users in an operational environment. According to Buede and Miller (2016: 180), “Performance elements of usability are ease of learning (learnability), ease of use (efficiency), ease of remembering (memorability), error rate, and subjectively pleasing (satisfaction).”<br />
|Ergonomics and human factors are used to assess and improve manufacturing and operational processes. They are also used to assess and improve the actual usability of products and services.<br />
|-<br />
|9. Engineering Management<br />
|Engineering managers and SEs work with program managers to develop and improve new products and services. <br />
|Engineering managers and IEs support operations managers responsible for manufacturing processes and the operation of systems providing products and services. <br />
|-<br />
|11. Information Engineering<br />
|Information Engineering is critical to the development of new products and services that are increasingly software intensive. Information engineering is relevant for model-based systems engineering software tools and databases, requirements management software tools and databases, and overall configuration management of the systems design and requirements baseline.<br />
|The Information Engineering knowledge area focuses on using data in information systems to facilitate decision-making and business communication.<br />
|-<br />
|13. Product Design and Development<br />
|SE focuses on the design of systems that provide products and services and the system life cycle. SE includes the technical processes for system design and verification and the technical management processes for project planning, assessment, and control; risk management; and decision management in the ''Systems Engineering Handbook'' (2015: 47-83, 104-121).<br />
|The knowledge area of the ISEBoK (2021: 53-46) focuses on the design of products and the product life cycle. It closely parallels the technical processes for system design and development of SEBoK.<br />
|-<br />
|Systems Deployment<br />
|Systems engineers participate in defining requirements, defining the architecture, and verification and validation of deployment systems needed to the deploy the system of interest, e.g., special transport equipment such as the Shuttle Carrier Aircraft (SCA) that NASA used to transport Space Shuttle orbiters. (Jenkins 2000)<br />
|Industrial engineers are more focused on air, ground, water, and intermodal logistics to include transportation and distribution of systems and products. <br />
|-<br />
|Updates, Upgrades, Modernization<br />
|Systems engineers are involved defining requirements, defining the architecture, and verification and validation of updates, upgrades, and modernization of systems. One way that this has been explained is that a second iteration of the systems engineering V-model is completed as the systems remains in service while a system change project is implemented (Ven, Talik, and Hulse 2012).<br />
|Industrial engineers are involved in manufacturing processes and supporting operations of systems to provide goods and services. Industrial engineers can help identify the need for updates, upgrades, and modernization of manufacturing and service processes and work with engineering managers, systems engineers, and design engineers to provide improved capabilities.<br />
|-<br />
|Service Life Extension<br />
|Systems engineers are involved in service life extension efforts in the same way that they are involved in updates, upgrades, and modernization of systems.<br />
|Industrial engineers are involved in service life extension efforts in the same way that they are involved in updates, upgrades, and modernization of systems.<br />
|-<br />
|System Maintenance<br />
|Systems engineers participate in defining requirements for maintenance across the life cycle of the system, determine the impact of maintenance constraints on the system requirements and the system architecture (Walden, et al. 2015: 97-98).<br />
|Industrial engineers provide engineering support to production processes maintenance and system maintenance to sustain operation of production and service processes and systems. <br />
|-<br />
|Logistics<br />
|Systems engineers participate in defining requirements for logistics across the life cycle of the system, determine the impact of maintenance constraints on the system requirements and the system architecture (Walden, et al. 2015: 97-98).<br />
|Industrial engineers are very involved in logistics planning and operations including supply chain management, transportation, and distribution.<br />
|-<br />
|Disposal and Retirement<br />
|Systems engineers identify requirements, define the architecture, and verification and validation of disposal and retirement needed to the disposition or retire the system of interest, e.g., nuclear material stabilization processes and equipment needed to disposition fissile nuclear materials to enable shutdown of the nuclear production facilities (Kenley, et al. 1999).<br />
|Industrial engineers plan for disposal and retirement as part of their product design process. Increasingly, industrial engineers must consider environmental impact and sustainability issues.<br />
|}<br />
<br />
= Roles in a System Life Cycle =<br />
Systems engineers and industrial engineers play important roles in a system life cycle. Figure 4 modifies a format from Buede and Miller (2016). It shows the system life cycle stages and, based on analysis in the previous section, identifies and summarizes the major roles of systems engineers, industrial engineers, and design engineers. Some processes have been aggregated to simplify the figure. <br />
<br />
[[File:SE&IE_lifecycle_view.png|thumb|center|700px|''Figure 4. Roles in a System Life Cycle.'' (SEBoK Original, adapted from Driscoll 2011)]]<br />
<br />
= Summary =<br />
In summary: <br />
<br />
* The SEBoK ''SE and Management'' Part is based on an ISO standard. IE has several related ISO standards. IISE does not link its body of knowledge to standards.<br />
* The SEBoK is more process focused, while IISEBoK focuses more on concepts and techniques.<br />
* SE and IE have overlapping bodies of knowledge.<br />
* The SEBoK and INCOSE's SE Handbook align with the system life cycle. The IISEBoK does not have an analogous organizing structure.<br />
* Systems engineers and industrial engineers both play important roles in the system life cycle with some overlapping responsibilities.<br />
<br />
= References =<br />
===Works Cited===<br />
Buede, D.M, W.D. Miller. 2016. ''The Engineering Design of Systems: Models and Methods''. Hoboken, NJ, USA: Wiley.<br />
<br />
DA PAM 70-3. 2008. ''Army Acquisition Procedures''. Pamphlet, January 28, 2008, Washington, DC, USA: Department of the Army.<br />
<br />
Environmental Protection Agency. ''Guidelines for Preparing Economic Analyses''. Accessed on November 19, 2021. Available: https://www.epa.gov/environmental-economics/guidelines-preparing-economic-analyses. <br />
<br />
IISE. 2021. ''IISE Body of Knowledge''. Institute of Industrial and Systems Engineers (IISE). Accessed on May 13, 2022. Available: https://www.iise.org/BodyofKnowledge.<br />
<br />
Institute of Industrial and Systems Engineers website. ''Origins of IISE.'' Accessed on November 13, 2021. Available: https://www.iise.org/details.aspx?id=295.<br />
<br />
International Council on Systems Engineering (INCOSE) website. ''What is systems engineering?'' Accessed February 17, 2022. Available: https://www.incose.org/about-systems-engineering/system-and-se-definition/systems-engineering-definition. <br />
<br />
International Organization for Standardization, standards website. Accessed on November 14, 2021. Available: https://www.iso.org/standards.html. <br />
<br />
ISO/IEC/IEEE 15288, 2015. ''Systems and software engineering-System life cycle processes''. Geneva, Switzerland: International Organization for Standardization.<br />
<br />
Jenkins, D.R. 2000. ''Boeing 747-100/200/300/sp.'' Airliner tech series, version 6. North Branch, MN, US: Specialty Press Publishers and Wholesalers.<br />
<br />
Kenley, B., B. Scott, B. Seidel, D. Knecht, F. Southworth, K. Osborne, N. Chipman, and T.A. Creque. 1999. "Program to Stabilize Nuclear Materials as Managed by the Plutonium Focus Area." Proceedings of Waste Management 1999. Tucson, AZ, US.<br />
<br />
Levis, A.H. and L.W. Wagenhals. 2000. "C4ISR architectures: I. Developing a Process for C4ISR Architecture Design" ''Systems Engineering.'' 3(4): 225-247.<br />
<br />
Raz, A.K., C.R. Kenley, and D.A. DeLaurentis. 2018, "System Architecting and Design Space Characterization". ''Systems Engineering.'' 21(3): 227-242.<br />
<br />
Salvendy, G. (ed.) 2001. ''[[Handbook of Industrial Engineering, Technology and Operations Management]],'' 3rd ed. Hoboken, NJ, USA: John Wiley & Sons, Inc.<br />
<br />
Van De Ken, M., J. Talik, and J. Hulse. 2012. "An Introduction to Applying Systems Engineering to In-Service Systems," Proceedings of the 2012 INCOSE International Symposium. 22(1):879-894. Rome, Italy. https://doi.org/10.1002/j.2334-5837.2012.tb01377.x.<br />
<br />
Wagenhals, L.W., S. Haider, and A.H. Levis. 2003. "Synthesizing Executable Models of Object-Oriented Architectures." ''Systems Engineering,'' 6(4): 266-300.<br />
<br />
Wagenhals, L.W., I. Shin, D. Kim, and A.H. Levis. 2000. "C4ISR architectures: II. A Structured Analysis Approach for Architecture Design." ''Systems Engineering,'' 3(4): 248-287.<br />
<br />
Walden, D.D., G.J. Roedler, K.J. Forsberg, R.D. Hamelin, and T.M. Shortell (ed.). 2015. ''INCOSE'' ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities,'' 4<sup>th</sup> Edition. Hoboken, NJ, USA: Wiley.<br />
<br />
Wymore, A.W. 1993. ''Model-Based Systems Engineering: An Introduction to The Mathematical Theory of Discrete Systems and to The Tricotyledon Theory of System Design.'' Boca Raton, FL, USA: CRC Press. <br />
<br />
Zandin, K.B. (ed.). 2001. ''[[Maynard's Industrial Engineering Handbook]]'', 5th ed. New York, NY, USA: McGraw-Hill.<br />
<br />
=== Primary References ===<br />
Salvendy, G. (ed.) 2001. ''[[Handbook of Industrial Engineering, Technology and Operations Management]],'' 3rd ed. Hoboken, NJ, USA: John Wiley & Sons, Inc.<br />
<br />
Zandin, K.B. (ed.). 2001. ''[[Maynard's Industrial Engineering Handbook]]'', 5th ed. New York, NY, USA: McGraw-Hill.<br />
<br />
=== Additional References ===<br />
none.<center>[[Further Insights into Geospatial/Geodetic Engineering|< Previous Article]] | [[Related Disciplines|Parent Article]] | [[Systems Engineering and Project Management|Next Article >]]</center><br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center><br />
<br />
[[Category:Part 6]][[Category:Knowledge Area]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=Further_Insights_into_Geospatial/Geodetic_Engineering&diff=65018
Further Insights into Geospatial/Geodetic Engineering
2022-05-18T12:49:10Z
<p>Mhaas: Added navigation links</p>
<hr />
<div>----<br />
<br />
'''''Lead Author: ''' Ulrich Lenk''<br />
<br />
----<br />
This article is part of the Systems Engineering and Geospatial/Geodetic Engineering (GGE) Knowledge Area. It discusses in more detail a selected set of topics that a beginner in {{Term|Geographic Information System (glossary)|Geographic Information Systems (GIS)}} and science or a systems engineer adopting respective techniques might be interested in or should be aware of. Topics discussed include {{Term|Body of Knowledge (glossary)|bodies of knowledge}} on geospatial technologies, various aspects associated with {{Term|geographic data (glossary)|geographic data}}, and standardization in the geospatial domain.<br />
<br />
==GIS related Bodies of Knowledge==<br />
The emphasis of the article [[Overview of Geospatial/Geodetic Engineering]] was to focus on to what extent {{Term|System (glossary)|systems}} and {{Term|System of Systems (SoS) (glossary)|systems of systems}} are dependent on {{Term|Geographic Information System (glossary)|GIS}} related technologies and where potential {{Term|Interface (glossary)|interfaces}} or contributions are. In order to provide now an improved but still brief overview of which topics are related in general to geospatial and geodetic engineering and how broad the geospatial {{Term|Domain (glossary)|domain}} actually is, a high-level introduction into existing {{Term|Body of Knowledge (glossary)|bodies of knowledge}} in the geospatial domain is provided here.<br />
<br />
The work on a {{Term|Body of Knowledge (glossary)|body of knowledge}} (BOK) for the geospatial domain actually goes back into the 1980s (cf. Kemp & Goochild 1991, cited in Stelmaszczuk-Górska et al. 2020), and since then at least two major workstreams have evolved. One in the United States that culminated first in 2006 with the publication of Edition 1 of the Geographic Information Science and Technology Body of Knowledge (GISTBoK) by the [https://www.ucgis.org/ University Consortium for Geographic Information Science (UCGIS)] (DiBiase et al. 2006). For the {{Term|GEOINT (glossary)|Geospatial Intelligence (GEOINT)}} discipline, a refinement was elaborated by the [https://usgif.org/ United States Geospatial Intelligence Foundation (USGIF)]. The UCGIS GISTBoK also formed the nucleus for the other workstream in Europe which started with the [http://www.gi-n2k.eu/ GI-N2K: Geographic Information – Need to Know] project (Vandenbroucke and Vancauwenberghe 2016) that aimed to better reflect European aspects in a BOK and to provide an {{Term|ontology (glossary)|ontological}} structure of concepts and relationships (Hofer et al. 2020). The European workstream was then further pursued as part of the [http://www.eo4geo.eu/ Earth Observation for Geoinformation project (EO4GEO)] that refined and extended the work from GI-N2K (Stelmaszczuk-Górska et al. 2020; Hofer et al. 2020).<br />
<br />
===UCGIS: Geographic Information Science and Technology Body of Knowledge (GISTBoK)===<br />
For the 2006 GISTBoK a hierarchical decomposition of the geospatial domain was conducted into 10 Knowledge Areas which were again divided into 73 Units and then into 329 Topics. There were over 1600 Learning Objectives listed in these topics. With the update that began in 2013 (Wilson 2014), there are also 10 Knowledge Areas in the current GISTBoK but they have changed partly versus the 2006 version. As of the beginning of 2022, there are 54 Units and 363 Topics. The current Knowledge Areas are:<br />
* Foundational Concepts, with 7 Units and 35 Topics;<br />
* Knowledge Economy, with 4 Units and 20 Topics;<br />
* Computing Platforms, with 5 Units and 28 Topics;<br />
* Programming and Development, with 5 Units and 23 Topics;<br />
* Data Capture, with 8 Units and 35 Topics;<br />
* Data Management, with 7 Units and 53 Topics;<br />
* Analytics and Modeling, with 9 Units and 70 Topics;<br />
* {{Term|Cartography (glossary)|Cartography}} and Visualization, with 6 Units and 36 Topics;<br />
* Domain Applications, with 44 Topics (with no categorization into Units); and<br />
* GIS&T and Society, with 3 Units and 19 Topics.<br />
It should be noted however that the GISTBoK is constantly evolving and for the latest version the respective [https://gistbok.ucgis.org/ GISTBoK online resource] has to be checked. Additionally, a feature of this BOK is that many Topics are linked with respective citable articles providing insights into the subjects at hand. The UCGIS also provides at its web site [https://www.ucgis.org/gis-t-body-of-knowledge (UCGIS BOK]) information on open educational resources on {{Term|Geographic Information System (glossary)|GIS}} and GIScience.<br />
<br />
===USGIF: GEOINT Essential Body of Knowledge===<br />
Aside from the activities hosted by the UCGIS that were mainly driven by academia, the USGIF published in 2014 the first version of its GEOINT Essential Body of Knowledge that targeted the {{Term|GEOINT (glossary)|GEOINT}} discipline. Among other sources, it was based on the 2006 GISTBoK (DiBiase et al. 2006) but extending it where necessary to better reflect the broader needs of GEOINT and related industries. The second version (Brooks et al. 2019) was published in 2019 after an 18 months period of preparation with a survey in the GEOINT community involving various subject matter experts that interpreted the results of the survey. It serves as a guide to what skills are required in the GEOINT discipline and acts as a blueprint for respective Certified GEOINT Professional exams (Brooks et al. 2019; Baber 2018). The GEOINT Essential Body of Knowledge version 2.0 is divided into three parts. The first one is related to “Technical Competencies” with the following areas:<br />
* {{Term|Geographic Information System (glossary)|GIS}} & Analysis Tools;<br />
* {{Term|remote sensing (glossary)|Remote Sensing}} & {{Term|Geographic Imagery (glossary)|Imagery}} Analysis; <br />
* Geospatial Data Management; and<br />
* Data Visualization.<br />
The second part is related to “Cross Functional Competencies” which cover general skills like soft skills or common GEOINT knowledge and practices suitable for the GEOINT practitioner, whereas the third part looks at “Emerging Competencies”, like data science, machine learning techniques, virtual reality. artificial intelligence, and unmanned aerial platforms.<br />
<br />
It is worth mentioning that, since 2015, USGIF also publishes the “State and Future of GEOINT Reports” on a yearly basis. These may also serve as a general reference on future trends in geospatial technologies.<br />
<br />
===Europe: The "GI-N2K: Geographic Information - Need to Know" and the "EO4GEO: Earth Observation for Geoinformation" BOKs===<br />
The GI-N2K project funded by the European Union's (EU) Erasmus Lifelong Learning Program and its BOK started as well with the 2006 GISTBoK (DiBiase et al. 2006) and had 10 Knowledge Areas. For these Knowledge Areas 63 sub-concepts were identified and further divided into 301 on level 3. However, in some instances level 3 was even further de-composed into level 4 and partly into level 5 concepts. At the end, 411 concepts were defined on these levels. Additional features that were provided with this BOK were curriculum design tools and a GeoWiki to enable discussion between experts.<br />
<br />
The most recent development in European GIS-related BOKs is the EO4GEO BOK that continues and further develops as part of the Erasmus+ Sector Skills Alliance project EO4GEO the work conducted in the GI-N2K project. As Earth Observation (EO) and {{Term|Geographic Information (glossary)|Geoinformation (GI)}} data sources, especially from the space sector, are gaining nowadays much more importance for data capture and updates of derivative data, the respective skills for data capture, information processing, standalone and combined analysis and associated applications need to be defined and matched or merged with the previous BOKs to reflect this change in academia, business and applications (Stelmaszczuk-Górska et al. 2020). An analysis revealed that "neither the American nor the European GIS&T (comment: Geographic Information Science and Technology) and GI-N2K BOKs include comprehensive information on EO" (Stelmaszczuk-Górska et al. 2020). Additionally, since there was a criticism that the previous BOKs were too much oriented along education driven by academia and too theoretical with a lack of practical aspects, an emphasis was made to “better align” the academically oriented EO4GEO BOK “with the business, professional, and industrial perspective” (Hofer et al. 2020) by analyzing a set of relevant business processes with regard to applicable concepts.<br />
<br />
The [http://www.eo4geo.eu/bok/ EO4GEO BOK] has at its highest level 14 subconcepts as follows:<br />
* Analytical Methods, with 14 subconcepts;<br />
* Conceptual Foundations, with 8 subconcepts;<br />
* {{Term|Cartography (glossary)|Cartography}} and Visualization, with 6 subconcepts;<br />
* {{Term|Design (glossary)|Design}} and Setup of {{Term|Geographic Information System (glossary)|Geographic Information Systems}}, with 4 subconcepts;<br />
* Data Modeling, Storage and Exploitation, with 5 subconcepts;<br />
* Geocomputation, with 4 subconcepts;<br />
* Geospatial Data, with 4 subconcepts;<br />
* {{Term|Geographic Information (glossary)|GI}} and Society, with 6 subconcepts;<br />
* Image processing and analysis, with 6 subconcepts;<br />
* Organizational and Institutional Aspects, with 5 subconcepts;<br />
* Physical principles, with 2 subconcepts;<br />
* Platforms, sensors and digital imagery, with 4 subconcepts;<br />
* Thematic and application domains, with 5 subconcepts; and<br />
* Web-based {{Term|Geographic Information (glossary)|GI}}, with 7 subconcepts.<br />
<br />
Similar as with the GIN-2K BOK, there are partly also further levels below the subconcepts. In addition to the BOK, it provides an occupational profile tool, a job offer tool, a curriculum design tool, a BOK annotation tool, a BOK matching tool and other educational features. For the concepts, their names are given along with descriptions and references. A set of 5 relationships between the concepts is maintained, and skills explaining the practical use of the EO*GEO knowledge are associated with the concepts (Hofer et al. 2020). The BOK exploration is supported by a graphical tool.<br />
<br />
== Geographic Data and Metadata ==<br />
<br />
=== Geographic Data ===<br />
Geospatial data is actually the fuel needed for any type of geographic application, whether it might be only for visualization purpose, e.g. as background information for real-time situational awareness applications, or for advanced spatial analytics involving different data sources and specific analysis methods. A first categorization into the two fundamental concepts of {{Term|geographic data (glossary)|geographic data}} has already been given in the SEBoK article [[Relationship between Systems Engineering and Geospatial/Geodetic Engineering]]. They are:<br />
<br />
* Continuous fields, i.e. spatially distributed phenomena with no clear limits or boundaries and representing “the real world as a finite number of variables, each one defined at every possible position” (Longley et al. 2015). For the case that repeated pattern of positions is used, the term raster data is commonly used, especially for the case that an equidistant matrix pattern is used. However, a matrix could potentially have different resolutions in columns and rows, or theoretically also other regular patterns could be involved, such as hexagonal patterns, but these applications are very rare.<br />
* Discrete objects or features, which are delimited by boundaries and potentially associated with a set of {{Term|attribute (glossary)|attribute}} data to describe them further beyond their spatial properties. This type of data is also termed vector data in a {{Term|Geographic Information System (glossary)|GIS}} context.<br />
<br />
Beyond these two fundamental concepts, the different aspects that need to be considered for geographic data when designing a system using this data are very diverse and cannot be treated in full detail here. A selection of important key words coming from practical experiences to be considered when implementing GIS databases include:<br />
* What data is actually needed (examples see below)?<br />
** At what scales shall the data be visualized, i.e. the level of detail needed.<br />
** Dimensionality: typical dimensionalities used in {{Term|Geographic Information System (glossary)|GIS}} technologies are:<br />
*** 2D, describing the earth surface in a flat plane, like a paper {{Term|map (glossary)|map}};<br />
*** 2.5D, with a unique z-value to a position in the horizontal plane;<br />
*** 3D, where all three dimensions are considered; and <br />
*** Time dimension: for the case of 3D data then 4D, but as also the former 2 cases may have variations in time this is treated here as time dimension.<br />
** What are the critical infrastructures that need to be shown, such as transport networks?<br />
* What standards need to be considered, such as {{Term|feature catalogue (glossary)|feature catalogues}}, interface and data format standards, data acquisition standards etc.?<br />
* What is the {{Term|positional accuracy (glossary)|positional accuracy}} required for the geographic data? This is typically associated with data acquisition method to be selected and obviously with the costs involved.<br />
* What is the level of semantic detail needed, e.g. how many {{Term|feature attribute (glossary)|feature attributes}} shall be captured for features / vector data and how big is the set of domain values from which they shall be selected?<br />
* Are there complex topological relations to be captured and maintained, i.e. to establish connectivity for the vector data, for example, for routing applications or utility networks?<br />
* Questions on updates:<br />
** How often does the data need to be updated? This is directly related to maintenance costs for the database, i.e. recurring costs to be considered, but also to availability of resources for the updates.<br />
** How shall the data be updated? Is it possible to use a central service for the data which is updated, i.e. can the responsibility for the updates be delegated?<br />
** What communication lines are used when data and updates are distributed in a system? Or is a service model the better choice as it realizes a single source of information principle? A systems engineers has to keep in mind that geographic data can reach considerable data volumes (depending on type of data terabytes and petabytes) that cannot be easily distributed over the air for example.<br />
* What are the data sources that may or have to be used? How are bounding conditions on the use of the data?<br />
** Authoritative data from a spatial data infrastructure, from international or national governmental agencies (or even intergovernmental agencies), such as national surveys like the USGS or the British Ordnance Survey, or on an international level the United Nations.<br />
** Commercial data sources, such as satellite imagery service providers, or mapping service providers.<br />
** Open sources, from activities like the [https://www.openstreetmap.org/ Open Street Map] or [https://www.openseamap.org/ Open Seamap] initiatives.<br />
** Copyrights and Intellectual Property Rights associated with the data sources.<br />
** Classification of data.<br />
** Bounding legal conditions (e.g. export control laws and regulations for export of data, as for example some satellite {{Term|resolution (of imagery) (glossary)|image resolutions}} may have export restrictions).<br />
** Liability aspects for the data, especially for the cases of legal boundaries, i.e. national borders. This is of particular relevance when borders are under dispute between neighboring countries!<br />
<br />
For implementation aspects again Tomlinson (2019) and Peters (2012) are referred to as well as the online successor to the latter text book, [http://www.wiki.gis.com/wiki/index.php/System_Design_Strategies System Design Strategies].<br />
<br />
=== Metadata for Geographic Data ===<br />
Whereas the section above discusses aspects of geographic data itself, it is also of fundamental importance to make this data available to or detectable by potential {{Term|User (glossary)|users}}. This is done by describing the data by metadata and having the metadata available, for example in a catalog where users can search for it. Whereas the Dublin Core data set (ISO 2017; ISO 2019b) defined by the Dublin Core Metadata Initiative is now used to describe general items, for the special case of geographic data, a set of dedicated ISO standards has been developed (ISO 2014, with its amendments ISO 2018 & ISO 2022; ISO 2020d). As such, ISO 19115 "provides information about the identification, the extent, the quality, the spatial and temporal aspects, the content, the {{Term|Spatial Reference(glossary)|spatial reference}}, the {{Term|Portrayal (glossary)|portrayal}}, distribution, and other properties of digital geographic data and services" (ISO 2014).<br />
<br />
=== Geocoding Systems, Localization and Geographic Search ===<br />
One further particular aspect looked at here is how a {{Term|Spatial Reference (glossary)|spatial reference}} for a {{Term|feature (glossary)|feature}} may be expressed. Certainly the most well-known way to describe a location technically or mathematically is by coordinates, either in 2 dimensions for the simple case of a plane, or in 3 dimensions or even adding a time dimension. Standardized ways to express {{Term|geographic coordinates (glossary)|geographic coordinates}} are covered by ISO 6709 (ISO 2009) but also {{Term|Cartesian coordinate system (glossary)|Cartesian coordinate systems}} are in use. However, a {{Term|Spatial Reference (glossary)|spatial reference}} may also be given by other types of {{Term|Geographic Identifier (glossary)|geographic identifiers}} where a location is expressed by a specific (sometimes non-numeric) code or name. A {{Term|gazetteer (glossary)|gazetteer}} is used to manage {{Term|Geographic Identifier (glossary)|geographic identifiers}}, such as geographic names, e.g. names of states, provinces, or other geographically identifiable {{Term|feature (glossary)|features}} such as lakes etc. Other codes in use are for example addresses (where it should be remembered that there are also different {{Term|postal address type (glossary)|postal address types}} in use), country codes (ISO 3166-1, ISO 2020a) and codes of country principal subdivisions such as states and provinces (ISO 3166-2; ISO 2020b), but there are many other, sometimes application or {{Term|Domain (glossary)|domain}} specific or even commercially developed geocodes.<br />
<br />
An example of a commercially developed and thus proprietary geococde is the [https://what3words.com/ What3words] system that is even in use as a postal addressing system in some countries. By dividing the Earth's surface into squares of about 3 meters by 3 meters and assigning unique 3 ordered words to each of them, the codes for each location are established. There are, however, several other systems available, like [http://geohash.org/ Geohash] or [https://www.mapcode.com/ Mapcode], which have no license restrictions.<br />
<br />
In general, geocodes may be categorized into non-hierarchical and hierarchical geocodes, while for the latter the accuracy of location position increases in a refinement/subdivision process, similar to adding more significant digits to a coordinate. A well-known dataset of geographic names often used in {{Term|Geographic Information System (glossary)|GIS}} applications is provided by [https://www.geonames.org/ geonames.org].<br />
<br />
These codes can then also be used to navigate in a geographic display, i.e. by inserting a geocode one can jump directly in the display to the respective position or features (described by positions) associated with the code. In case the code is ambiguous (as it is sometimes the case for geographic names like city names) a disambiguation could be given, in order to clarify the selection. While this approach is mainly used to navigate in a display or to find a location, it should not be confused with the topic of efficiently searching in multidimensional spatial databases. This is not treated here as it relates to database management system design and implementation, including spatial indexing, for example with space filling curves.<br />
<br />
=== Example: The United Nations 14 Global Fundamental Geospatial Data Themes ===<br />
The set of geographic data to be used in a system will always be dependent on the purpose and goals of the system at hand, and therefore no general purpose structure can be provided here. Some examples of geographic data have already been given in the SEBoK article [[Relationship between Systems Engineering and Geospatial/Geodetic Engineering]] in the frame of Geospatial Aspects in Modeling and Simulation. In order to extend this for a better and broader overview of what may considered as relevant in general, the following list of geospatial data themes may serve as a first indicator. It has been elaborated as "The 14 Global Fundamental Geospatial Data Themes" by the United Nations Committee of Experts on Global Geospatial Information Management (UN-GGIM 2019).<br />
* Global {{Term|Geodetic Reference Frame (glossary)|Geodetic Reference Frame}};<br />
* Addresses, such as {{Term|postal address type (glossary)|postal addresses}}, see above;<br />
* Buildings and Settlements;<br />
* Elevation and Depth, e.g. provided by {{Term|Digital Elevation Model (glossary)|Digital Elevation Models}} and {{Term|Digital Terrain Model (DTM) (glossary)|Digital Terrain Models (DTM)}};<br />
* Functional Areas, such as administrative or legislative areas;<br />
* Geographical Names, e.g. {{Term|Geographic Identifier (glossary)|geographic identifiers}} managed and provided by a {{Term|gazetteer (glossary)|gazetteer}}, see above;<br />
* Geology and Soils;<br />
* {{Term|Land Cover (glossary)|Land Cover}} and {{Term|Land Use (glossary)|Land Use}};<br />
* Land Parcels, e.g. a cadastre or a land register;<br />
* Physical Infrastructure, including industrial and utility facilities;<br />
* Population Distribution;<br />
* {{Term|orthoimage (glossary)|Orthoimagery}}, which is a special case of {{Term|Geographic Imagery (glossary)|geographic imagery}} in orthogonal projection;<br />
* Transport Networks, e.g. rails, roads, waterways and air transport routes associated potentially with connectivity relations; and<br />
* Water, including rivers, lakes and marine features.<br />
<br />
The UN-GGIM (2019) provides more insights and information into the themes, e.g. what standards are available and possible sources for data. In {{Term|Geographic Information System (glossary)|GIS}} where often multiple geographic data sets from different sources are processed in a combined way, these data sets are organized into a stacked set of layers which may be for example switched on and off individually for visualization purpose.<br />
<br />
== Standardization Organizations active in the Geospatial Domain ==<br />
In the following selected international civil {{Term|Organization (glossary)|organizations}} are briefly introduced that publish standards related to the geospatial {{Term|Domain (glossary)|domain}}.<br />
<br />
=== The Open Geospatial Consortium (OGC) ===<br />
The Open Geospatial Consortium (OGC) was founded in 1994 and publishes open standards and specifications in the geospatial domain. The documents are created in a member-driven consensus process. The most successful standards are the Web Map Service (WMS; OGC 2006) and the Web Feature Service (WFS; OGC 2010), but OGC has published about 70 implementation standards and about 20 abstract specifications.<br />
<br />
OGC works closely with ISO TC211 (see next section), and some documents are jointly elaborated and published. For example, the above mentioned WMS is also an ISO standard (namely ISO 2005), as is the WFS (ISO 2010). Another example is the specification of the Geography Markup language (OGC, 2012; and ISO, 2015 & 2020a) that is published by both OGC and ISO. Special care has to be taken which version is published in which document since they are not necessarily published in the same versions at the same time. Besides the cooperation with ISO TC211, OGC has in addition other alliance partners, such as the Object Management Group (OMG), the Organization for Advancement of Structured Information Standards (OASIS), the Web3D Consortium, the World Wide Web Consortium (W3C), the International Hydrographic Organization (IHO) and the World Meteorological Organization (WMO) (both see below), and also with other ISO TCs.<br />
<br />
Several companies well-known to the general public such as Amazon Web Services, Apple, Google, Microsoft, Oracle and SAP, and universities, governmental, inter-governmental and non-governmental organizations as well as individuals are members of the OGC at different levels of membership, summing up to more than 500 members.<br />
<br />
=== ISO TC 211 “Geographic information/Geomatics” ===<br />
The International Organization for Standardization (ISO) is certainly the best known international standardization organization in the world and is organized into technical committees which develop the standards. The Technical Committee (TC) 211 is related to “Geographic information/Geomatics”. TC211 has published more than 80 standards, most of them as part of the 191xx family of standards, including abstract specifications and interface standards together with the OGC. Several ISO TC211 standards are referenced in the list of references below. TC211 also maintains the Online [https://isotc211.geolexica.org/ Multi-Lingual Glossary of Terms (MLGT)] at Geolexica that was used to define terms used in this Knowledge Area. Typically ISO standards are also promulgated as national standards, or as European standards from the respective European standardization organizations.<br />
<br />
=== International Hydrographic Organization (IHO) ===<br />
Founded in 1921 as the International Hydrographic Bureau and renamed in 1970 to the International Hydrographic Organization (IHO), IHO is an intergovernmental organization that standardizes and coordinates activities in the area of {{Term|Hydrography (glossary)|hydrography}}, nautical {{Term|Cartography (glossary)|cartography}} and thus {{Term|Nautical Chart (glossary)|nautical charts}} to ensure initially and still primarily the safety of navigation. With the increasing interest in the marine environment, e.g. for the installation of offshore wind farms, the importance of the activities of IHO has even more increased as it publishes standards for the creation and exchange of digital hydrographic data (IHO 2020; IHO 2017a; IHO 2000, with its appendices) that may serve as a {{Term|Geographic Information System (glossary)|GIS}} base {{Term|Map (glossary)|map}} {{Term|layer (glossary)|layer}}, and also for the portrayal of data (IHO 2014). The way how hydrographic offices can support the creation of spatial data infrastructures by providing data for the marine environment is discussed in IHO (2017b). With the revision of its standards to adhere to ISO TC211 standards, IHO is now transitioning to the S-100 family of standards (IHO 2018).<br />
<br />
=== World Meteorological Organization (WMO) ===<br />
Originally founded in 1873 as the International Meteorological Organization and renamed in 1950 into the World Meteorological Organization (WMO), WMO is an intergovernmental organization and specialized agency of the United Nations. According to its mandate as described on its [https://wmo.int/ website], it provides the framework for international cooperation "in the areas of meteorology (weather and climate), operational hydrology and related geophysical sciences" and facilitates "free and unrestricted exchange of data and information, products and services in real- or near-real time on matters relating to safety and security of society, economic welfare and the protection of the environment." WMO defines several data formats for the exchange of weather information (WMO 2019 & 2021a/b).<br />
<br />
Clearly the scientific background needed to create meteorological information goes far beyond of what is needed in standard {{Term|Geographic Information System (glossary)|GIS}} applications. From a GIS perspective, weather information may be treated as one or several information {{Term|layer (glossary)|layer(s)}}, and due to the typically required real- or near-real time information respective online interfaces have to be established with weather data providers, whether they are national weather services or commercial companies.<br />
<br />
==References==<br />
===Works Cited===<br />
Baber, M. 2018. “Geospatial Intelligence and National Security.” In: The Geographic Information Science & Technology Body of Knowledge (1st Quarter 2018 Edition), John P. Wilson (Ed.). DOI:10.22224/gistbok/2018.1.2<br />
<br />
Hofer, B., S. Casteleyn, E. Aguilar-Moreno, E.-M. Missoni-Steinbacher, F. Albrecht, R. Lemmens, S. Lang, J. Albrecht, M. Stelmaszczuk-Górska, G. Vancauwenberghe and A. Monfort-Muriach. 2020. “Complementing the European earth observation and geographic information body of knowledge with a business-oriented perspective.” Transactions in GIS 24(3):587-601. DOI: 10.1111/tgis.12628.<br />
<br />
IHO. 2000. IHO Transfer Standard for Digital Hydrographic Data. Publication S-57, Edition 3.1.0. November 2000, Monaco: International Hydrographic Bureau.<br />
<br />
IHO. 2014. Specifications for Chart Content and Display Aspects of ECDIS. Publication S-52, Edition 6.1(.1). September 2014, Monaco: International Hydrographic Organization.<br />
<br />
IHO. 2017a. ENCs: Production, Maintenance and Distribution Guidance. Publication S-65, Edition 2.1.0, May 2017. Monaco: International Hydrographic Organization.<br />
<br />
IHO. 2017b. Spatial Data Infrastructures "The Marine Dimension". Guidance for Hydrographic Offices. Publication C-17, Second Edition, Version 2.0.0, January 2017. Monaco: International Hydrographic Organization.<br />
<br />
IHO. 2018. IHO Universal Hydrographic Data Model. Publication S-100, Edition 4.0.0, December 2018. Monaco: International Hydrographic Organization.<br />
<br />
IHO. 2020. IHO Standards for Hydrographic Surveys. Publication S-44, Edition 6.0.0, September 2020. Monaco: International Hydrographic Organization.<br />
<br />
ISO. 2005. ISO 19128:2005, Geographic information - Web map server interface. ISO 19128, First edition 2005-12-01. Geneva, Switzerland: International Organization for Standardization.<br />
<br />
ISO. 2009. ISO 6709:2009, Standard representation of geographic point location by coordinates. Geneva, Switzerland: International Organization for Standardization.<br />
<br />
ISO. 2010. ISO 19142:2010, Geographic information - Web Feature Service. ISO 19142, First edition 2010-12-15. Geneva, Switzerland: International Organization for Standardization.<br />
<br />
ISO. 2014. ISO 19115-1:2014, Geographic information - Metadata - Part 1: Fundamentals. ISO 19115-1, First edition 2014-04-01. Geneva, Switzerland: International Organization for Standardization.<br />
<br />
ISO. 2015. ISO 19136-2:2015, Geographic information - Geography Markup Language (GML) - Part 2: Extended schemas and encoding rules. ISO 19136-2, First edition 2015-08-01. Geneva, Switzerland: International Organization for Standardization.<br />
<br />
ISO. 2017. ISO 15836-1:2017, Information and documentation — The Dublin Core metadata element set — Part 1: Core elements. ISO 15836-1, 2017-05. Geneva, Switzerland: International Organization for Standardization.<br />
<br />
ISO. 2018. ISO 19115-1:2018, Geographic information - Metadata - Part 1: Fundamentals Amendment 1. ISO 19115-1, 2018-02. Geneva, Switzerland: International Organization for Standardization.<br />
<br />
ISO. 2019a. ISO 19115-2:2019, Geographic information - Metadata - Part 2: Extensions for acquisition and processing. ISO 19115-2, Second edition 2019-01. Geneva, Switzerland: International Organization for Standardization.<br />
<br />
ISO. 2019b. ISO 15836-2:2019, Information and documentation - The Dublin Core metadata element set - Part 2: DCMI Properties and classes. ISO 15836-2, First edition 2019-12. Geneva, Switzerland: International Organization for Standardization.<br />
<br />
ISO. 2020a. ISO 19136-1:2020, Geographic information - Geography Markup Language (GML) - Part 1: Fundamentals. ISO 19136-1, First edition 2020-01. Geneva, Switzerland: International Organization for Standardization.<br />
<br />
ISO. 2020b. ISO 3166-1:2020, Codes for the representation of names of countries and their subdivisions – Part 1: Country codes. Geneva, Switzerland: International Organization for Standardization.<br />
<br />
ISO. 2020c. ISO 3166-2:2020, Codes for the representation of names of countries and their subdivisions – Part 2: Country subdivision code. Geneva, Switzerland: International Organization for Standardization.<br />
<br />
ISO. 2020d. ISO 19115-1:2020, Geographic information - Metadata - Part 1: Fundamentals Amendment 2. ISO 19115-1, 2020-11. Geneva, Switzerland: International Organization for Standardization.<br />
<br />
Longley, P.A., M.F. Goodchild, D.J. Maguire, and D.W. Rhind. 2015. Geographic Information Science and Systems, (4th edition). New York, Chichester, Weinheim: John Wiley & Sons, Inc.<br />
<br />
OGC. 2006. OpenGIS® Web Map Server Implementation Specification. Version: 1.3.0, OGC® document: OGC® 06-042, URL: https://www.ogc.org/standards/wms<br />
<br />
OGC. 2010. OpenGIS Web Feature Service 2.0 Interface Standard. Version: 2.0.0, OGC® document: OGC 09-025r1, URL: https://www.ogc.org/standards/wfs<br />
<br />
OGC. 2012. OGC® Geography Markup Language (GML) – Extended schemas and encoding rules. Version: 3.3.0, OGC® document: OGC 10-129r1, Available: https://www.ogc.org/standards/gml<br />
<br />
Stelmaszczuk-Górska, M. A., E. Aguilar-Moreno, S. Casteleyn, D. Vandenbroucke, M. Miguel-Lago, C. Dubois, R. Lemmens, G. Vancauwenberghe, M. Olijslagers, S. Lang, F. Albrecht, M. Belgiu, V. Krieger, T. Jagdhuber, A. Fluhrer, M. J. Soja, A. Mouratidis, H. J. Persson, R. Colombo, and G. Masiello. 2020. Body of Knowledge for the Earth Observation and Geoinformation Sector - A Basis for Innovative Skills Development, Int. Arch. Photogramm. Remote Sens. Spatial Inf. Sci., XLIII-B5-2020, 15–22, DOI: https://doi.org/10.5194/isprs-archives-XLIII-B5-2020-15-2020 .<br />
<br />
UN-GGIM. 2019. The Global Fundamental Geospatial Data Themes. New York, United Nations.<br />
<br />
Vandenbroucke, D. and G. Vancauwenberghe. 2016. “Towards a New Body of Knowledge for Geographic Information Science and Technology.” Micro, Macro & Mezzo Geoinformation 2016 (6):7-19.<br />
<br />
Wilson, J.P. 2014. Geographic Information Science & Technology Body of Knowledge 2.0 Project. Final Report 2014 University Consortium for Geographic Information Science Symposium, Pasadena, California.<br />
<br />
WMO. 2019. WMO-No. 306 Manual on Codes - International Codes Volume I.1, Annex II to the WMO Technical Regulations, Part A – Alphanumeric Codes. Geneva, Switzerland: World Meteorological Organization.<br />
<br />
WMO. 2021a. WMO-No. 306 Manual on Codes - International Codes Volume I.2, Annex II to the WMO Technical Regulations, Part B – Binary Codes & Part C – Common Features to Binary and Alphanumeric Codes. Geneva, Switzerland: World Meteorological Organization.<br />
<br />
WMO. 2021b. WMO-No. 306 Manual on Codes - International Codes Volume I.2, Annex II to the WMO Technical Regulations, Part D – Representations derived from data models. Geneva, Switzerland: World Meteorological Organization.<br />
<br />
===Primary References===<br />
DiBiase, D., M. DeMers, A. Johnson, K. Kemp, A.T. Luck, B. Plewe, and E. Wentz (Eds.). 2006. ''[[Geographic Information Science and Technology Body of Knowledge]]''. Ed. 1. Ithaca, NY: University Consortium for Geographic Information Science. https://www.ucgis.org/gis-t-body-of-knowledge<br />
<br />
Brooks, T., Kantor, C., Spuria, L. and Quinn, K. (Eds.). 2019. ''[[The Geospatial Intelligence Essential Body of Knowledge]]'', Version 2.0/2019, Compiled by the United States Geospatial Intelligence Foundation. January 2019. Accessed January 20, 2021. Available: https://usgif.wpengine.com/wp-content/uploads/2020/11/ebk2019.pdf.<br />
<br />
Peters, D. 2012. ''[[Building a GIS: Geographic Information System Planning for Managers]]'', (2nd edition). Redlands, CA: Esri Press.<br />
<br />
Tomlinson, R.F. 2019. ''[[Thinking About GIS: Geographic Information System Planning for Managers.]]'', (5th edition). Redlands, CA: Esri Press.<br />
<br />
===Additional References===<br />
Website of the EO4GEO BOK. Accessed January 20, 2022. Available: http://www.eo4geo.eu/bok/.<br />
<br />
Website of IHO. Accessed February 02, 2022. Available: https://iho.int/.<br />
<br />
Website of ISO TC211. Accessed February 02, 2022. Available: https://www.isotc211.org/.<br />
<br />
Websites of ISO TC211 at the [https://www.iso.org/ ISO website]. Accessed February 02, 2022. Available: https://www.iso.org/committee/54904.html and https://committee.iso.org/home/tc211.<br />
<br />
Website of the OGC: Accessed February 02, 2022. Available: https://www.ogc.org/.<br />
<br />
Website of the UCGIS GISBoK. Accessed January 20, 2022. Available: https://gistbok.ucgis.org/.<br />
<br />
Website of WMO. Accessed February 02, 2022. Available: https://wmo.int/.<br />
--------<br />
<center>[[Relationship between Systems Engineering and Geospatial/Geodetic Engineering|< Previous Article]] | [[Systems Engineering and Geospatial/Geodetic Engineering|Parent Article]] | [[Systems Engineering and Industrial Engineering|Next Article >]]</center><br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center><br />
<br />
[[Category:Topic]][[Category:Part 6]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=Relationship_between_Systems_Engineering_and_Geospatial/Geodetic_Engineering&diff=65017
Relationship between Systems Engineering and Geospatial/Geodetic Engineering
2022-05-18T12:47:15Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div>----<br />
'''''Lead Author: ''' Ulrich Lenk''<br />
----<br />
This article discusses the relationship between {{Term|Systems Engineering (glossary)|Systems Engineering (SE)}} and Geospatial/Geodetic Engineering (GGE) as reflected through relationships between several {{Term|Specialty Engineering (glossary)|Specialty Engineering}} disciplines listed in INCOSE (2015) and GGE. For most of these disciplines, there are also SEBoK articles in the Knowledge Area[[Systems Engineering and Quality Attributes | SE and Quality Attributes]].<br />
<br />
==Geospatial Aspects in the INCOSE Specialty Engineering Activities==<br />
{{Term|System (glossary)|Systems}} that directly include geospatial components and {{Term|System Element (glossary)|system elements}}, or that perform {{Term|navigation (glossary)|navigation}} operations or deal with referenceable objects in their broadest interpretations require dedicated contributions from the geodetic/geospatial {{Term|Domain (glossary)|domain}}. Those contributions should be achieved by integrating appropriate subject matter experts into SE teams.<br />
<br />
The following sections briefly describe possible geospatial solutions or contributions which may directly support some of the {{Term|Specialty Engineering (glossary)|Specialty Engineering}} activities in INCOSE (2015).<br />
<br />
===Environmental Engineering/Impact Analysis===<br />
Analyzing a spatial distribution or dispersal of pollutants typically depends on specific modules that have been integrated into {{Term|Geographic Information System (glossary)|Geographic Information Systems (GIS)}}; e.g. a plume modeler will estimate how chemicals dissolve in the atmosphere under certain meteorological conditions. Other applications determine run-off for flooding simulations, or reveal dependencies between different types of environmental parameters during geospatial analysis. The list of such applications is long. The Knowledge Area (KA) [[Systems Engineering and Environmental Engineering]] provides more information.<br />
<br />
===Interoperability Analysis===<br />
{{Term|Interoperability (glossary)|Interoperability}} has been a major issue in geospatial {{Term|Infrastructure (glossary)|infrastructures}} for decades. The [http://www.opengeospatial.org/ Open Geospatial Consortium] (OGC), founded in 1994, published its first standard (OpenGIS Simple Features Specification) in 1997. Other {{Term|Organization (glossary)|organizations}} also publish standards including the [https://www.iso.org/home.html International Organization for Standards] (ISO) with its [https://www.isotc211.org/ Technical Committee 211 Geographic information/Geomatics] (see also [https://committee.iso.org/home/tc211 here]), the [https://iho.int International Hydrographic Organization] (IHO) and the [https://www.nato.int North Atlantic Treaty Organization] (NATO). For meteorological data, the [https://www.wmo.int/ World Meteorological Organization] (WMO) standardizes respective services and data formats. Typically, these bodies closely cooperate.<br />
<br />
Using these standards can lead to significant {{Term|Cost (glossary)|cost}} savings in the {{Term|Systems Development (glossary)|development}} and operation of {{Term|System (glossary)|systems}} and thus contributes to another INCOSE {{Term|Specialty Engineering (glossary)|Specialty Engineering}} activity: Affordability/Cost-Effectiveness/{{Term|Life Cycle Cost (LCC) (glossary)|Life Cycle Cost}} Analysis. NASA funded a study that was conducted by Booz Allen Hamilton (2005). The study found that the {{Term|Project (glossary)|project}} that adopted and implemented geospatial interoperability standards:<br />
*had a risk-adjusted Return on Investment (ROI) of 119.0%. This ROI is a “Savings to Investment” ratio over the 5-year project {{Term|Life Cycle (glossary)|life cycle}}.<br />
*had a risk-adjusted Return on Investment (ROI) of 163.0% over a 10-year period.<br />
*saved 26.2% compared to the project that relied upon proprietary standards.<br />
Another finding was that standards-based projects have lower {{Term|Maintenance (glossary)|maintenance}} and operations {{Term|Cost (glossary)|costs}} than those relying exclusively on proprietary products for data exchange.<br />
<br />
As a general conclusion from the above, there are substantial contributions from the geospatial {{Term|Domain (glossary)|domain}} that support interoperability analyses.<br />
<br />
===Logistics Engineering ===<br />
According to INCOSE (2015), “{{Term|Logistics (glossary)|Logistics}} engineering … is the engineering discipline concerned with the identification, {{Term|Acquisition (glossary)|acquisition}}, {{Term|Procurement (glossary)|procurement}}, and provisioning of all support resources required to sustain operation and {{Term|Maintenance (glossary)|maintenance}} of a {{Term|System (glossary)|system}}.” Amongst others, the following elements supporting logistics engineering are identified in INCOSE (2015) that have a direct relation to geospatial, {{Term|Geographic Information System (glossary)|GIS}} and PNT/{{Term|Satellite Positioning System (glossary)|Global Navigation Satellite Systems (GNSS)}} technologies:<br />
*{{Term|Sustainment (glossary)|Sustaining}} engineering;<br />
*Training and training support;<br />
*Supply support;<br />
*Facilities and {{Term|Infrastructure (glossary)|infrastructures}}; and<br />
*Packaging, handling, storage, and transportation (PHS&T).<br />
Typical keywords associated with related activities are:<br />
*“Technical surveillance” where, e.g., fielded {{Term|System (glossary)|systems}} are monitored with means of geodetic engineering techniques, such as deformation analysis of structures and sites,<br />
*“{{Term|Simulation (glossary)|Simulation}}” that requires virtual 3D {{Term|Environment (glossary)|environments}} and {{Term|Geographic Information System (glossary)|GIS}},<br />
*“Facilities” that are nowadays managed with Building Information Modeling (BIM) techniques which have a close connection to {{Term|Geographic Information System (glossary)|GIS}}, based on cadastre data from local authorities,<br />
*“Transfer” and “transportation” where objects, material and goods are moved in space involving amongst others {{Term|Geographic Information System (glossary)|GIS}} with navigable {{Term|Map (glossary)|map}} used for planning routes and {{Term|navigation (glossary)|navigation}} during transport.<br />
Sometimes, GNSS and real-time GIS technologies are also used for tracking cargo of interest for safety reasons.<br />
<br />
===Reliability, Availability, and Maintainability===<br />
How {{Term|Reliability (glossary)|reliable}} is a map, or, in the digitized world, a {{Term|geographic data (glossary)|geographic data}} set displayed on screen or a mobile device? That depends firstly on the source of data, i.e. how reliable the source is, and on the other hand even for trusted data sources on the need to update that data set according to operational requirements and the changes that take place in the landscape of the area of interest. Updating and otherwise {{Term|Maintainability (glossary)|maintaining}} geospatial databases is a costly and sometimes time-consuming operation (again tied to the {{Term|Specialty Engineering (glossary)|Specialty Engineering}} activity “Affordability/Cost-Effectiveness/{{Term|Life Cycle Cost (LCC) (glossary)|Life Cycle Cost}} Analysis”). Efficiently updating geospatial databases is discussed from a technical perspective in Peters (2012) and, at least to a certain extent, must be reflected as well in the design of a geospatial data {{Term|Infrastructure (glossary)|infrastructure}}. Using central services to provision {{Term|geographic data (glossary)|geographic data}} is one possibility to address this issue since then, only one data set needs to be updated according to the single source of information principle. Others will access this data set via services to always receive the latest version of available data. The required {{Term|Availability (glossary)|availability}} constraints clearly must be addressed in the {{Term|Design (glossary)|design}} of the IT {{Term|Infrastructure (glossary)|infrastructure}} that hosts such a geospatial database, and also IT {{Term|Security (glossary)|security}} aspects need to be considered.<br />
<br />
===Resilience Engineering===<br />
In recent years there has been an increasing awareness of the vulnerabilities of systems depending on GPS/GNSS. {{Term|Resilience (glossary)|Resilient}} PNT is heavily discussed and alternatives like eLoran and Satelles are often mentioned in this context. According to the Royal Academy of Engineering (2013), “all critical {{Term|Infrastructure (glossary)|infrastructure}} and {{Term|Safety (glossary)|safety}} critical systems that require accurate GNSS derived time and or timing should be specified to operate with holdover technology for up to three days.” This source also lists other recommendations to be considered for {{Term|Design (glossary)|system design}}.<br />
<br />
A source that provides example cases on a regular basis is the [https://rntfnd.org Resilient Navigation and Timing Foundation] (RNT Foundation). Examples of official reports in the US and the UK are also Wallischeck (2016) and Royal Academy of Engineering (2011). Jamming and GPS disruptions actually occur and sometimes official warnings are issued, e.g. by the US Coast Guard (DHS 2016). According to an [https://rntfnd.org/2017/07/28/g20-jams-gps/ RNT Foundation notice], there was an official warning from flight authorities during the 2017 G20 event in Hamburg, Germany. It cautioned to consider the possibility of GPS disruptions caused by intentionally initiated activities and actions to protect the G20 conference.<br />
<br />
Prudent systems engineers will consider such dependencies and ensure to the degree practical that the systems at hand are {{Term|Resilience (glossary)|resilient}} and fault tolerant, i.e. those systems do not terminate safe and reliable operation in the absence of GNSS signals, or cause major problems when they need to continue to communicate with other systems.<br />
<br />
===System Safety Engineering ===<br />
Although it may not be straightforward, even in {{Term|System (glossary)|System}} {{Term|Safety (glossary)|Safety}} Engineering there are aspects that may be supported by geodetic and surveying engineering. One example may be the monitoring of dams, bridges and buildings etc., i.e. to what extent constructions move under differing environmental conditions, especially when subject to wind or water pressure or heat. Another example is the monitoring of natural objects such as volcanoes or slopes to detect early the possibility of future volcanic eruptions or potential landslides, or the monitoring of fracture zones or areas prone to earthquakes.<br />
<br />
===Usability Analysis/Human Systems Integration===<br />
Geographical displays sometimes form a central part of user interfaces. In such cases, proper usability analysis and other aspects of {{Term|Human Systems Integration (HSI) (glossary)|Human Systems Integration}} (all of these activities are part of {{Term|Human Factors (glossary)|Human Factors}} Engineering, HFE), geospatial expertise may be required. But beyond this, in HFE several other aspects are considered covering the general interaction of {{Term|User (glossary)|users}} with systems (Stanton et al. 2013). Nevertheless, in displaying virtual {{Term|Environment (glossary)|environments}}, HFE is related to the science and application of {{Term|Cartography (glossary)|cartography}} (Kraak and Ormeling 2020) because the latter deals not only with {{Term|Portrayal (glossary)|portrayal}} of {{Term|geographic data (glossary)|geographic data}} but also heavily with the different ways of human perception and abstraction of spatial phenomena, especially in dependence of the different scales the data is displayed.<br />
<br />
==Geospatial Aspects in Modeling and Simulation==<br />
{{Term|Model (glossary)|Modeling}} and {{Term|Simulation (glossary)|simulation}} is a broad field and heavily used in various disciplines and as such also in different SE {{Term|Life Cycle Process (glossary)|life cycle processes}}. Geospatial technologies contribute to these activities amongst others by providing {{Term|geographic data (glossary)|geographic data}} to create realistic {{Term|Environment (glossary)|environments}}, either for 2- or 3-dimensional applications. According to INCOSE (2015), such a {{Term|Model (glossary)|model}} is then termed a “formal geometric model”. When considering temporal aspects and phenomena as well, 4-dimensional models are used. The modeler has to discern what types of {{Term|Geographic Information (glossary)|geographic information}} must being modeled, and whether they are discrete objects which can be delimited with boundaries or whether they are continuous fields representing “the real world as a finite number of variables, each one defined at every possible position” (Longley et al. 2015), like temperature. For a comprehensive introduction to the general theory of geographic representation in GIS with continuous fields and discrete objects and how these concepts may be integrated see Longley et al. (2015), Goodchild et al. (2007) and Worboys and Duckham (2004).<br />
<br />
In traditional {{Term|Cartography (glossary)|cartography}} a {{Term|Map (glossary)|map}} {{Term|Model (glossary)|model}} was described by the well-known map legend that explained the {{Term|Portrayal (glossary)|portrayal}} of depicted {{Term|Feature (glossary)|features}} or phenomena. Today, fairly straightforward models for perspective visualization of landscapes are created using so-called {{Term|Digital Terrain Model (DTM) (glossary)|Digital Terrain Models (DTM)}} and rendering them with {{Term|Geographic Imagery (glossary)|geographic imagery}}. With these types of models no further descriptive information may be extracted besides geometric information and visual interpretation of the imagery to decide what is actually there. A well-known application for this is Google Earth. Vector models can provide more information. Discrete objects in a vector model may be further described by attributes, e.g. the width of a street. Vector models are created using so-called “{{Term|Feature Catalog (glossary)|feature catalogues}}” that define which real world objects and domain values are to be represented. A typical military {{Term|Feature Catalog (glossary)|feature catalogue}} was created by the Defence Geospatial Information Working Group (DGIWG) for worldwide military mapping projects and is called the [https://www.dgiwg.org/FAD/overview.jsp DGIWG Feature Data Dictionary] (DFDD). {{Term|Feature Catalog (glossary)|Feature catalogues}} vary with different levels of modeling scales, i.e. large-scale models provide a higher granularity than small-scale models that provide more of an overview.<br />
<br />
INCOSE (2015) lists the following purposes for {{Term|Model (glossary)|models}} throughout the {{Term|System (glossary)|system}} {{Term|Life Cycle (glossary)|life cycle}}:<br />
*Characterizing an existing system,<br />
*{{Term|Mission (glossary)|Mission}} and system {{Term|Concept (glossary)|concept}} formulation and evaluation,<br />
*System {{Term|Architecture (glossary)|architecture}} {{Term|Design (glossary)|design}} and {{Term|Requirement (glossary)|requirements}} flow-down,<br />
*Support for systems {{Term|Integration (glossary)|integration}} and {{Term|Verification (glossary)|verification}},<br />
*Support for {{Term|Training (glossary)|training}}, and<br />
*{{Term|Knowledge (glossary)|Knowledge}} Knowledge capture and {{Term|Design (glossary)|system design}} evolution.<br />
The second and fifth purposes may be supported by geospatial technologies; i.e. data and software components that create, store, simulate and visualize/portray real world or virtual {{Term|Model (glossary)|models}} of {{Term|Environment (glossary)|environments}} where a {{Term|System (glossary)|system}} is going to be deployed, or where operations are going to take place (Tolk 2012). “Mission and system concept formulation and evaluation” tie to the definition of the {{Term|Concept of Operations (ConOps) (glossary)|Concept of Operation (ConOPS)}}. By analyzing different variants of {{Term|System Deployment and Use (glossary)|system deployment}} and categorizing them based on defined cost functions, it is possible to optimize a {{Term|Design (glossary)|system design}} to provide a solid basis for decision making.<br />
<br />
==Conclusions==<br />
Geodetic and geospatial technologies and services play a fundamental role in many {{Term|System of Systems (SoS) (glossary)|systems of systems}} and stand-alone systems. The general public is often not aware how strongly their lives and activities depend on these assets to provide and maintain critical {{Term|Infrastructure (glossary)|infrastructure}} such as electric power and communications services. Against this background, systems engineers often need mastery of GGE knowledge and access to GGE subject matter experts and as a consequence, Geospatial and Geodetic Engineering may be considered as well a {{Term|Specialty Engineering (glossary)|Specialty Engineering}} Discipline for {{Term|System (glossary)|Systems}} and {{Term|System of Systems (SoS) (glossary)|Systems of Systems}} Engineering endeavors. <br />
==References==<br />
===Works Cited===<br />
Booz Allen Hamilton. 2005. ''Geospatial Interoperability Return on Investment Study.'' NASA Geospatial Interoperability Office, April 2005.<br />
<br />
DHS 2016. US Department of Homeland Security, US Coast Guard, Safety Alert 01-16 Global Navigation Satellite Systems – Trust, But Verify. Washington, DC, January 19, 2016.<br />
<br />
Goodchild, M.F., M. Yuan and Th.J. Cova. 2007 “Towards a general theory of geographic representation in GIS.” International Journal of Geographical Information Science, 21(3):239-260.<br />
<br />
Royal Academy of Engineering. 2013. ''Extreme space weather: impacts on engineered systems and infrastructure.'' London, UK, Royal Academy of Engineering.<br />
<br />
Royal Academy of Engineering. 2011. ''Global Navigation Space Systems: reliance and vulnerabilities.'' London, UK, Royal Academy of Engineering.<br />
<br />
Stanton, N.A., P.M. Salmon, L.A. Rafferty, G.H. Walker, and Chr. Baber. 2013. ''Human Factors Methods: A Practical Guide for Engineering and Design,'' (2nd edition). Farnham: Ashgate Publishing Limited.<br />
<br />
Tolk, A. 2012. ''Engineering Principles of Combat Modeling and Distributed Simulation.'' Hoboken, New Jersey: John Wiley & Sons, Inc.<br />
<br />
Wallischeck, E. 2016. ''GPS Dependencies in the Transportation Sector.'' Cambridge, MA: U.S. Department of Transportation, Office of the Assistant Secretary for Research and Technology, John A Volpe National Transportation Systems Center.<br />
<br />
Worboys, M.F., M. Duckham. 2004. ''GIS: A Computing Perspective,'' (2nd edition). Bristol, PA: Taylor & Francis.<br />
<br />
===Primary References===<br />
INCOSE. 2015. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', (4th edition). San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-04.<br />
<br />
Kraak, M.-J. and F. J. Ormeling. 2020. ''[[Cartography: Visualization of Geospatial Data]]'', (4th edition). London, New York: Taylor & Francis.<br />
<br />
Longley, P.A., M.F. Goodchild, D.J. Maguire, and D.W. Rhind. 2015. ''[[Geographic Information Science and Systems]]'', (4th edition). New York, Chichester, Weinheim: John Wiley & Sons, Inc.<br />
<br />
Peters, D. 2012. ''[[Building a GIS: Geographic Information System Planning for Managers]]'', (2nd edition). Redlands, CA: Esri Press.<br />
===Additional References===<br />
None.<br />
<br />
----<br />
<br />
<center>[[Overview of Geospatial/Geodetic Engineering|< Previous Article]] | [[Systems Engineering and Geospatial/Geodetic Engineering|Parent Article]] | [[Further Insights into Geospatial/Geodetic Engineering|Next Article >]]</center><br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center><br />
<br />
[[Category:Part 6]]<br />
[[Category:Knowledge Area]]<br />
[[Category:Systems Engineering and Geospatial/Geodetic Engineering]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=Technical_Leadership_in_Systems_Engineering&diff=65016
Technical Leadership in Systems Engineering
2022-05-18T11:57:46Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div>----<br />
'''''Lead Author:''''' ''Heidi Davidz''<br />
----<br />
Leadership is an important but often overlooked component of technical projects and programs. It addresses the performance of people: their behaviors, their ability to think individually and collectively, and their motivation and energy. Technical leadership in systems engineering creates the environmental conditions conducive to good performance: support of shared understanding, innovation, problem solving, resilience and learning. Leadership is thus complementary to management, which directs specific activities to deliver outputs. A systems engineering leader may lead a team of systems engineers for a project or program, or may be the only systems engineer in a team of diverse members involved in project or program (e.g. other engineers, IT personnel, service providers). There are various models and styles of leadership and key to success is matching leadership to the needs of a situation. ‘‘‘Models’’’ of leadership describe the mechanisms by which leadership arises and operates (e.g. situationally-driven or caused by a charismatic individual). ‘’’Styles’’’ of leadership describe the manner in which a leader (or a leadership team) leads (e.g. task-focused or people-focused; autocratic, democratic or “laissez-faire” (Lewin et al., 1939)). <br />
<br />
There is a vast amount of literature addressing leadership issues from multiple points of view, including philosophical, psychological and emotional considerations (Yukl, 2012). This article highlights key aspects of leadership theory to help systems engineers understand how they may influence the success of their team and organization. Leadership theory provides the basic building blocks for adapting leadership behaviors at work. The pragmatic aspects of leading team members involved in systems engineering are summarized in [[Technical Leadership in Systems Engineering#Implications for technical leadership in systems engineering|section 1.11]]. This section highlights the need to use different approaches to leadership across the systems engineering context, and it is therefore important be able to understand and adopt the leadership behaviors discussed in the preceding sections, as judged appropriate. Related knowledge areas and articles are in the Part 5 Knowledge Area [[Enabling Systems Engineering|Part 5 Enabling Systems Engineering]] and the Part 6 Knowledge Area [[Systems Engineering and Project Management]].<br />
<br />
==Attributes of Effective Leaders==<br />
<br />
=== Traditional Attitudes to Technical Leadership ===<br />
The need for leadership in an engineering environment has not been widely emphasized or understood. Traditional academic engineering curricula do not cover the development of leadership skills, and industry professionals tend to be task-oriented, with project leaders perceived in terms of power and authority (Toor and Ofori, 2008). In many cases, technical organizations focus on management rather than leadership. “Managers are people who do things right while leaders are people who do the right thing” (Bennis and Nanus, 1985). Doing the right thing is not only about identifying the right approach in the first place; it is also about taking responsibility for understanding and challenging the progression of a project or program in a continuous manner. It is now recognized that leadership is a critical component of successful projects and programs, and that technical leadership is likely to be a distributed responsibility.<br />
=== Great Man Theories: Traits and Charisma Models of Leadership ===<br />
Early concepts of leadership were driven by views of leaders as heroic figures, with particular qualities that made them different to other people. The notion of “charisma” was used to describe the ability to charm and influence followers. Numerous studies have been conducted to try and define the particular personality traits that made someone a born leader. The findings are not clear-cut, partly because there are many different models of personality which produce different results (Hippocrates first identified 4 personality dimensions in the 5th Century BC, and many different conceptualizations have been devised since then). Personality tests should be used with great caution because each test has been developed for specific purposes and contexts, and is only valid within those parameters. For tests to be valid they must undergo a strict set of tests with extensive data sets, and then they must be used exactly as specified by the validation process. The current best consensus of evidence is that there are 5 main dimensions of personality: ‘’’Extraversion’’’ (talkative, sociable); ‘’’Agreeableness’’’ (good natured, co-operative); ‘’’Conscientiousness’’’ (responsible, tidy); ‘’’Neuroticism’’’ (general level of anxiety or composure); and ‘’’Openness’’’ (to new experiences). This 5-Factor model has good validity across literate populations, but even this model may not be universal (Gurven at al., 2013). There is some evidence that extraversion is associated with leadership roles, but this is not always a predictor of success, and may reflect a cultural stereotype which leads to people who behave like leaders being more likely to get leadership roles. Different contexts will change the value of extraversion (and other traits) in a leader. (See Judge et al. (2002) for a meta-analysis of the literature).<br />
<br />
In business settings, the Myers-Briggs Type Indicator (MBTI) personality test is often used as part of guided discussions to assist with self-development (although it lacks the important personality dimension of ‘neuroticism’). People can use their MBTI profiles to help them use their strengths more effectively. Occasionally, MBTI is misused as a basis for selection, especially for leadership roles. The evidence indicates this is not justified (National Research Council, 1991). <br />
=== Transactional and Transformational Leadership Styles ===<br />
Certain behaviors have been associated with successful leadership. These behaviors arise from the style of leadership and particularly the attention paid to the task compared to team relationships. Such differences are described as transactional and transformational styles (Burns, 1978). Transactional leadership is closely allied to management, focused on defined task outputs and incentivizing people to follow directions by rewarding and punishing.<br />
<br />
Transformational leadership is concerned with achieving outcomes through the development of the people (team building), building trust, developing a shared vision, motivation, cultivating relationships and sharing knowledge. Both types of leadership have value, but transformational leadership is needed for developing the culture of an organization, and for ensuring qualities such as safety, adaptability, learning and improvement. It is usually considered the most valuable form of leadership.<br />
<br />
Understanding that different styles have value for different situations provides the basis for leadership models that recognize the interactions between style and situation. Fiedler’s Contingency Model, Hersey et al.’s Situational Model and House’s Path-Goal Theory (all described below) provide useful variations on this approach.<br />
=== Contingency Model of leadership ===<br />
Fielder’s Contingency Model (1964) states that there is no one best style of leadership. Effectiveness is about the match between leadership style (defined as task or relationship-oriented) and situation (defined by: the degree to which the leader is supported by the group; the degree to which the task is clearly structured; and the degree to which the leader can reward and punish team members). Fiedler devised a way of assessing leaders’ styles by measuring their attitude to their ‘least preferred co-worker’ or LPC. In general terms, leaders who are more negative about their LPC are task-oriented and focus on organizing. Leaders who are more positive towards their LPCs are more able to avoid conflict, promote innovation and learning and are better at making complex decisions. In moderate situations (not extreme in any of the three situation dimensions), the more positive, relationship-oriented leaders appear to be more successful (Valle & Avella, 2003). This contingency model of leadership was found to predict leadership style in an information systems engineering environment, where leadership functions were distributed across technical experts and the end-user (Franz, 1985).<br />
<br />
=== Situational Theory === <br />
Situational Theory offers a model of leadership in which any individual leader adapts his or her style according to the needs of the situation. For example, they can learn to change from being task-focused to being relationship focused. They may also adapt according to their own changing status. Hersey, Blanchard and Johnson (2001) describe four modes that leaders can adapt between, according to the nature of the members of the team or organization: delegating, supporting, coaching, and directing. In this situational model, leadership is a learned skill based on understanding context and self-awareness. <br />
<br />
=== Path-Goal Model ===<br />
The Path-Goal Theory describes the leader’s role as helping followers to develop behaviors that <br />
allow them to achieve their goals (House and Mitchell, 1974). Leaders are facilitators for others’ achievements, e.g. providing resources, associations, knowledge and support. Leaders are members of a community of practice united in a common enterprise and sharing a common culture: history, values, ways of doing things, and ways of talking (Drath and Palus, 1994). In technical leadership, this means helping technical followers to perform effectively in their tasks, and in systems engineering this means facilitating pathways of communication between different areas, encouraging attitudes and behaviors that promote integrated perspectives.<br />
<br />
=== Authentic Leadership ===<br />
Somewhat in contrast to the principle of leading by adapting style, and thus in effect “acting the part”, research on leaders being “authentic” evaluates the effectiveness of staying true to one’s own natural style. Successful authentic leaders are described as positive, leading from the heart, concerned with ethics, building on trust, motivating people to achieve challenging tasks. According to the authentic leadership literature (e.g., Gardner et al., 2011; Walumbwa et al., 2008), authentic leaders display four types of behaviors. These include balanced processing (taking evidence from all sides), internalized moral perspective (driven more by morality than external pressures), relational transparency (openly sharing thoughts and feelings), and self-awareness (understanding of self and how others view them) (Gardner et al., 2011). These behaviors are likely to lead to a team having trust in the leader, which will be important in a technical context where safely achieving the right outcome= in a complex situation is paramount.<br />
<br />
Allied to authentic leadership in terms of behaviors is the concept of Servant Leadership, described as having seven key practices: self-awareness; listening; inverting the pyramid (leadership hierarchy); developing your colleagues; coaching, not controlling; unleashing the energy and intelligence of others; and foresight. Keith (2012), and Sipe and Frick (2009) have a similar list: servant leaders are individuals of character, put people first, are skilled communicators, are compassionate collaborators, use foresight, are systems thinkers, and exercise moral authority.<br />
<br />
The servant leadership elements of Empowerment, Standing Back / Sharing Credit, Courage / Risk Taking, Humility, Authenticity, and Stewardship were shown to have a statistically significant correlation with innovation output from engineering teams when applied at a frontline team leadership level (McCleave and Capella, 2015).<br />
<br />
=== Complexity Leadership and the Leadership Process ===<br />
Authentic and servant leadership styles place a leader in the role of a facilitator, rather than a director; someone who can leverage the capabilities of the team and create synergistic benefits. This perspective is taken a step further in the model of leadership that comes from complexity theory. <br />
<br />
Complexity Leadership describes leadership as promoting emergent adaptive outcomes from organizations (such as learning and innovation). Organizations are considered to be complex adaptive systems and leadership can take three forms: administrative, adaptive and enabling. Each form will vary itself according to its locus in an organizational hierarchy. The complex adaptive functions provide the adaptive capability while the bureaucratic functions provide the coordinating structures. Leadership should disentangle these two types of functions in a way that enhances the effectiveness of the organization (Marion & Uhl-Bien, 2001). In this model, leadership is mostly about developing interactions.<br />
<br />
Complexity leadership is differentiated from leaders as individuals, because in some cases leadership is about a function rather than a person. In a technical situation such as a Systems Engineering team, this will be an important consideration, as different people will have technical expertise and will be required to provide leadership in areas such as understanding, challenging and communicating. Systems engineering teams consist of members from diverse disciplines with diverse interests. Silos of self-interest must be broken down (or at least effective communication among silos must be established and a balance between global system concerns and provincial disciplinary interests must be maintained.)<br />
<br />
Manz and Sims (1989) also see leadership as a process, but they focus on self-leadership within each individual more than the behaviors and actions of a few select people designated as formal leaders in an organization. With this perspective, most people have some contribution to leadership. <br />
=== Followership ===<br />
Equally important is the concept of followership. A leader can only lead with effective followers. In technical situations, where a distributed process of leadership may be needed, this is especially important. The study of followership is much less developed than that of leadership, although they are two sides of the same coin. Uhl-Bien et al. (2014) have conducted a review of the literature to date and identify two theoretical frameworks for understanding followership: a role-based approach and a process approach. They warn against too much focus on a leader role and not enough on the leadership process, and suggest that understanding followership can help with:<br />
<br />
* Recognizing the importance of follower roles, following behaviors, and the leadership process <br />
* Understanding leadership processes and its outcomes as a function of leaders and followers <br />
* Identifying effective followership behaviors <br />
* Embedding context in the leadership process<br />
* Recognizing that leadership can flow in all directions <br />
* Understanding why and how managers are not always able to co-construct leadership with their subordinates <br />
* Developing followership <br />
<br />
This perspective is supportive of a distributed leadership function and is helpful for supporting people who have leadership roles as a consequence of their technical knowledge rather than their desire to lead or comfort with doing so.<br />
<br />
Associated with followership development is the nature of motivation within the individuals that the leader wishes to influence. The term “motivation” has been used to describe a range of possible causes of behavior, and no single theory can explain all situations. A useful distinction, however, is the difference between “intrinsic” and “extrinsic” motivation. The former relates to factors arising from emotions, ambitions, expectations and other internal states of an individual, and tends to be the focus of transformational leaders (see [[Technical Leadership in Systems Engineering#Transactional and Transformational Leadership Styles|section 1.3]]). The latter relates to factors arising from external factors such as threats, rewards, and social pressure, and tends to be the focus of transactional leaders (also in [[Technical Leadership in Systems Engineering#Transactional and Transformational Leadership Styles|section 1.3]]). It is important to recognize that there are cultural and professional differences in the strength of internal and external causes of motivation. One famous model of motivation by Maslow (1943), the “Hierarchy of Needs”, is useful to assess a range of potential factors, but does not have scientific validity and is based on a rather narrow Western 20th Century perspective. For example, it does not explain why people are willing to undergo physical hardship to conquer higher level challenges; or why some cultures are collectivist while others are individualistic. (A useful review of these culture differences can be found in Triandis et al., 1988).<br />
<br />
A more actionable approach to motivation emphasizes an individual’s mental model of what is important (valence), what their own role is in achieving it (instrumentality), and how able they are to achieve it (expectancy). This was first described by Vroom (1964) and has led to the concept of ‘empowering’ individuals (e.g. Conger and Kanungo, 1988). The Path-Goal model of leadership ([[Technical Leadership in Systems Engineering#Path-Goal Model|section 1.6]]) aims to facilitate performance by addressing these aspects of motivation. This approach to motivation, called Expectancy Theory, can help leaders understand how to motivate employees through challenge and self-belief (Isaac, Zerbe, and Pitt, (2001). <br />
<br />
An attempt to understand motivation at the organizational level has led to the concept of “organizational energy” (Cole, Bruch and Vogel, 2005). According to the existing overall energy type in an organization, a leader should adopt a different motivational strategy to achieve the optimum “productive” energy, which is described as high intensity and positive. A resignative energy (low intensity, negative) requires the development of a vision, empowerment and challenge. A corrosive energy (high intensity, negative) requires better communication and the development of trust. A comfortable energy (low intensity, positive) requires the identification of an external threat. <br />
<br />
=== Competencies ===<br />
Leadership competencies are the knowledge and skills required by individuals and teams for making leadership effective. Sometimes traits and other individual differences are added to skills and knowledge to create a “Competency Framework” for the leadership characteristics needed for a role. Communication, managing staff by supporting and providing feedback, and emotional competence are often featured in these frameworks. It is important to distinguish between those characteristics that are learned and those that are based on traits. Learned competencies can be enhanced through personal development; innate individual differences could be acquired for a role through personnel selection (although selection based on personality is not recommended: see [[Technical Leadership in Systems Engineering#Great Man Theories: Traits and Charisma Models of Leadership|section 1.2]]). As indicated above, leadership depends on many behaviors, including matching style to situations, effective followership, and individual leadership. <br />
<br />
A number of roles will be required in a team, and ideally these may be distributed to individuals with the apposite competencies. Emotional competence has been the focus of much recent research and some studies show a strong correlation with effective leadership (e.g. Cavallo and Brienza, 2006, who used the Emotional Competence Inventory©).<br />
<br />
Daniel Goleman has extended and publicized the concept of emotional intelligence (an innate characteristic) and the competencies (skills that can be learned) that put it into practice. He describes how emotional aptitudes can preserve relationships, protect our health and improve our success at work (Goleman, 1998).<br />
<br />
Goleman differentiates 5 main categories of competence. The first three are about self-management and the last two are about being effective in relationships.<br />
#Self-awareness: accurate self-assessment, emotional awareness and self-confidence<br />
#Self-regulation: innovation, adaptability, conscientiousness, trustworthiness and self-control<br />
#Motivation: optimism, commitment, initiative and achievement, drive<br />
#Empathy: developing others, service orientation, political awareness, diversity, active listening and understanding others<br />
#Social skills: communication, influence, conflict management, leadership, bond building, collaboration, cooperation and team capabilities<br />
Emotional Intelligence is most associated with transformational and situational leadership.<br />
<br />
Communication skills are also highlighted in most leader competency frameworks. These skills are about communicating to other people and listening and being communicated to by other people. Some skills are about engagement, others about sharing understanding. In particular, avoiding hidden assumptions and understanding others’ perspectives are important. Communication can take place in many ways, especially with the help of IT and social media. Each mode of communication has advantages and disadvantages. Consideration should be given to how important it is to have face-to-face communication (usually better, but especially for complex matters and when emotions are involved). Although this takes more time and effort, it will often save time and effort in the long term by reducing misunderstandings and negative emotions. Nikoi (2014) presents a collection of studies that investigated the way in which communication works across media and teams.<br />
<br />
Communication may be synchronous or asynchronous, broadcast or individual, dialogue or one-way. Bowman (2004) has a useful summary of the advantages and disadvantages of different communication channels. <br />
<br />
Some competencies that are often associated in the literature with good leadership are listed in Table 1. The relevance of these will depend on the style and the situation/context.<br />
<br />
Some commonly cited attributes of effective leaders are listed in Table 1 below.<br />
{| <br />
|+ '''Table 1. Attributes of Effective Leaders (Fairley 2009).''' <br>Reprinted with permission of the IEEE Computer Society. All other rights are reserved by the copyright owner.<br />
|-<br />
!<br />
!<br />
|-<br />
| Listening carefully<br />
| Maintaining enthusiasm<br />
|-<br />
| Delegating authority <br />
| Saying “thank you” <br />
|-<br />
| Facilitating teamwork<br />
| Praising team for achievements<br />
|-<br />
| Coordinating work activities<br />
| Accepting responsibility for shortcomings<br />
|-<br />
| Facilitating communication<br />
| Coaching and training <br />
|-<br />
| Making timely decisions<br />
| Indoctrinating newly assigned personnel<br />
|-<br />
| Involving appropriate stakeholders <br />
| Reconciling differences and resolving conflicts<br />
|-<br />
| Speaking with individual team members on a frequent basis<br />
| Helping team members develop career paths and achieve professional goals <br />
|-<br />
| Working effectively with the project/program manager and external stakeholders<br />
| Reassigning, transferring, and terminating personnel as necessary<br />
|}<br />
<br />
Characteristics that result in effective leadership of systems engineering activities include behavioral attributes, leadership style, and communication style. In addition, a team leader for a systems engineering project or program has management responsibilities that include, but are not limited to: developing and maintaining the systems engineering plan, and establishing and overseeing the relationships between the project/program manager and project/program management personnel. <br />
<br />
=== Implications for technical leadership in systems engineering ===<br />
Leadership can have a significant impact on engineering performance (Kolb, 1995) and resilience (Flin, 2006). The models and styles of leadership described above emphasize the power of social skills: the ability to relate to and connect with other people. This appears to be particularly true for the sorts of situations that system engineering leaders are likely to find themselves in: working on complex problems with other professionals who are willing to follow but need to be confident in the leader’s technical skill and trustworthiness. The technical leader should possess not only essential technical knowledge but should also have positive values, high levels of ethics, morality, leadership from the heart, personal capabilities, out-of-the-box thinking, interpersonal skills, etc. (Lloyd-Walker and Walker, 2011).<br />
<br />
In a systems engineering context it is useful to recognize that different leadership functions may be distributed across a team. Some leadership functions will be knowledge focused, but it may be necessary to have a ‘facilitator’ (complexity) leader to ensure that the team follows the most appropriate leadership at any time. Each organization will have particular leadership requirements, which should be articulated in a behavioral framework in order to identify the most effective leadership styles and competencies, and where and how they should be applied.<br />
<br />
Leadership capability for systems engineers should therefore be seen as a distributed capability to be developed across engineers. NASA takes a systems approach to developing leadership in their Systems Engineering Leadership Development Program (SELDP). They define technical leadership as the ‘art’ of systems engineering. Technical leadership includes broad technical domain knowledge, engineering instinct, problem solving, creativity, and the leadership and communication skills needed to develop new missions and systems. It focuses on systems design and technical integrity throughout the life cycle. A system’s complexity and the severity of its constraints drive the need for systems engineering leadership (Williams and Reyes, 2012).<br />
<br />
Selecting leaders by promoting the best technical performers or the most ambitious candidates is not an effective way of ensuring good leadership in an organization or program. For this reason, companies such as General Electric, Motorola, Toyota, Unilever, Raytheon, and Northrop Grumman use internal leadership academies to develop their leadership capability according to their needs (Daniels, 2009). A role model approach may be effective only if the appropriate role model is paired with a candidate, with good leadership characteristics that are valid for the situation (Yukl, 2012). <br />
<br />
More effective approaches would involve developing competencies that can be learned through example, experience and reflection. The most effective methods will depend on the competencies needed, the type of organization, and the opportunities. They could include coaching, mentoring, shadowing, ‘assistant-to’ trial periods, and career management to provide experience (e.g. Fast-track).<br />
<br />
There must also be an element of self-development: systems engineers should recognize the impact that people (or ‘soft’) issues have on the performance of a technical team and organization and learn how to adjust their own behavior and facilitate the behavior of others.<br />
<br />
===Behavioral Attributes===<br />
Behavioral attributes are habitual patterns of behavior, thought, and emotion that remain stable over time (Yukl 2013). Positive behavioral attributes enable a systems engineering leader to communicate effectively and to make sound decisions, while also taking into consideration the concerns of all stakeholders. Desirable behavioral attributes for a systems engineering leader include characteristics such as (Fairley 2009):<br />
*Aptitude - This is exhibited by the ability to effectively lead a team. Leadership aptitude is not the same as knowledge or skill but rather is indicative of the ability (either intuitive or learned) to influence others. Leadership aptitude is sometimes referred to as charisma or as an engaging style.<br />
*Initiative - This is exhibited by enthusiastically starting and following through on every leadership activity.<br />
*Enthusiasm - This is exhibited by expressing and communicating a positive, yet realistic attitude concerning the project, product, and stakeholders.<br />
*Communication Skills - These are exhibited by expressing concepts, thoughts, and ideas in a clear and concise manner, in oral and written forms, while interacting with colleagues, team members, managers, project stakeholders, and others. <br />
*Team Participation - This is exhibited by working enthusiastically with team members and others when collaborating on shared work activities.<br />
*Negotiation - This is the ability to reconcile differing points of view and achieve consensus decisions that are satisfactory to the involved stakeholders.<br />
*Goal Orientation – This involves setting challenging but not impossible goals for oneself, team members, and teams.<br />
*Trustworthiness - This is demonstrated over time by exhibiting ethical behavior, honesty, integrity, and dependability in taking actions and making decisions that affect others.<br />
Weakness, on the other hand, is one example of a behavioral attribute that may limit the effectiveness of a systems engineering team leader.<br />
===Personality Traits===<br />
The concept of “personality traits” was initially introduced in the early 1900's by Carl Jung, who published a theory of personality based on three continuums: introversion-extroversion, sensing-intuiting, and thinking-feeling. According to Jung, each individual has a dominant style which includes an element from each of the three continuums. Jung also emphasized that individuals vary their personality traits in the context of different situations; however, an individual’s dominant style is the preferred one, as it is the least stressful for the individual to express and it is also the style that an individual will resort to when under stress (Jung 1971). The Myers-Briggs Type Indicator (MBTI), developed by Katherine Briggs and her daughter Isabel Myers, includes Jung’s three continuums, plus a fourth continuum of judging-perceiving. These four dimensions characterize 16 personality styles for individuals designated by letters, such as ISTP (Introverted, Sensing, Thinking, and Perceiving). An individual’s personality type indicator is determined through the answers the person has provided on a questionnaire (Myers 1995) combined with the individual’s self-assessment which is done one to one with a qualified practitioner or in a group setting. MBTI profiles are widely used by coaches and counselors to help individuals assess how their personality type will affect how they might react in a particular profession and make suggestions about which professions might suit their individual preferences. It should never be used to decide which profession would be "most comfortable and effective” as the MBTI measures preference not ability. The MBTI has also been applied to group dynamics and leadership styles. Most studies indicate that groups perform better when a mixture of personality styles work together to provide different perspectives. Some researchers claim that there is evidence that suggests that leadership styles are most closely related to an individual’s position on the judging-perceiving scale of the MBTI profile (Hammer 2001). Those on the judging side of the scale are more likely to be “by the book” managers, while those on the perceiving side of the scale are most likely to be “people-oriented” leaders. “Judging” in the MBTI model does not mean judgmental; rather, a judging preference indicates a quantitative orientation and a perceiving preference indicates a qualitative orientation. The MBTI has its detractors (Nowack 1996); however, MBTI personality styles can provide insight into effective and ineffective modes of interaction and communication among team members and team leaders. For example, an individual with a strongly Introverted, Thinking, Sensing, and Judging personality index (ITSJ) may have difficulty interacting with an individual who has a strongly Extroverted, Intuiting, Feeling, Perceiving personality index (ENFP). <br />
===Leadership Styles and Communication Styles===<br />
There is a vast amount of literature pertaining to leadership styles and there are many models of leadership. Most of these leadership models are based on some variant of Jung’s psychological types. One of the models, the Wilson Social Styles, integrates leadership styles and communication styles (Wilson 2004). The Wilson model characterizes four kinds of leadership styles: <br />
* Driver leadership style - This is exhibited when a leader focuses on the work to be accomplished and on<br />
specifying how others must do their jobs.<br />
* Analytical-style leadership - This emphasizes collecting, analyzing, and sharing data and information. An<br />
analytical leader asks others for their opinions and recommendations to gather information.<br />
* Amiable leadership style – This is characterized by emphasis on personal interactions and on asking others<br />
for their opinions and recommendations.<br />
* Expressive leadership style – Like the amiable style, this also focuses on personal relationships, but an<br />
expressive leader tells others rather than asking for opinions and recommendations.<br />
When taken to extremes, each of these styles can result in weakness of<br />
leadership. By focusing too intently on the work, "drivers" can provide too much or too little guidance and direction. Too little guidance occurs when the individual is preoccupied with her or his personal work, while too much guidance results in micromanagement, which limits the personal discretion for team members. Drivers may also be insensitive to interpersonal relationships with team members and others. Analytical leaders may provide too much information or may fail to provide information that is obvious to them, but not their team members. They do not like to discuss things they already know or that are irrelevant to the task at hand. Like driver-style leaders,<br />
they may be insensitive to interpersonal relationships with other individuals. Amiable leaders focus on interpersonal relationships in order to get the job done. They may exhibit a dislike of those who fail to interact with them on a personal level and may show little concern for those who show little personal<br />
interest in them. Expressive leaders also focus on interpersonal relationships. In the extreme, an expressive leader may be more interested in stating their opinions than in listening to others. Additionally, they may play favorites and ignore those who are not favorites. While these characterizations are gross oversimplifications, they serve to illustrate leadership styles that may be exhibited by systems engineering team leaders. Effective team leaders are able to vary their leadership style to accommodate the particular context and the needs of their constituencies without going to extremes; but as emphasized by Jung, each individual has a preferred comfort zone that is least stressful and to which an individual will resort during times of added pressure. <br />
<br />
===Communication Styles===<br />
An additional characterization of the Wilson model is the preferred style of communication for different leadership styles, which is illustrated by the dimensions of assertiveness and responsiveness.<br />
<br />
[[File:Dimensions_of_Communication_Styles.png|600px|thumb|center|'''Figure 1. Dimensions of Communication Styles (Fairley 2009).''' Reprinted with permission of the IEEE Computer Society. All other rights are reserved by the copyright owner.]]<br />
<br />
Task-oriented assertiveness is exhibited in a communication style that emphasizes the work to be done rather than the people who will do the work, while the people-oriented communication style addresses personnel issues first and tasks secondly. A tell-oriented communication style involves telling rather than asking, while an ask-oriented assertiveness emphasizes asking over telling. Movies, plays, and novels often include caricatures of extremes in the assertiveness and responsiveness dimensions of Wilson communication styles. An individual’s communication style may fall anywhere within the continuums of assertiveness and responsiveness, from extremes to more moderate styles and may vary considering the situation. Examples include:<br />
* Driver communication style exhibits task-oriented responsiveness and tell-oriented assertiveness. <br />
*Expressive communication style shares tell-oriented assertiveness with the driver style but favors people-oriented responsiveness. <br />
*Amiable communication style involves asking rather than telling (as does the analytical style) and emphasizes people relationships over task orientation (as does the expressive style). <br />
*Analytical communication style exhibits task-oriented responsiveness and ask-oriented assertiveness. <br />
The most comfortable communication occurs when individuals share the same communication styles or share adjacent quadrants in Figure 1. Difficult communication may occur when individuals are in diagonal quadrants; for example, communication between an extreme amiable style and an extreme driver style. Technical leaders and others can improve communications by being aware of different communication styles (both their own and others) and by modifying their communication style to accommodate the communication styles of others.<br />
<br />
===Management Responsibilities===<br />
Leading a systems engineering team involves communicating, coordinating, providing guidance, and maintaining progress and morale. Managing a project, according to the PMBOK® Guide (PMBOK 2013), involves application of the five process groups of project management: initiating, planning, executing, monitoring and controlling, and closing. Colloquially, systems engineering project/program management is concerned with making and updating plans and estimates, providing resources, collecting and analyzing product and process data, working with the technical leader to control work processes and work products, as well as managing the overall schedule and budget. Good engineering managers are not necessarily good technical leaders and good technical leaders are not necessarily good engineering managers; the expression of different personality traits and skill sets is required. Those who are effective as both managers and leaders have both analytical and interpersonal skills, although their comfort zone may be in one of managing or leading. Two management issues that are typically the responsibility of a systems engineering team leader are: <br />
*Establishing and maintaining the division of responsibility among him or herself, the systems engineering team leader, and the project/program manager. <br />
*Developing, implementing, and maintaining the systems engineering plan (SEP).<br />
<br />
Relationships between systems engineering and project management are addressed in the Part 6 Knowledge Area (KA) of the SEBoK, [[Systems Engineering and Project Management]]. Also see the Part 5 Knowledge Area [[Enabling Teams]] for a discussion of the relationships between a project/program manager and a systems engineering technical leader.<br />
<br />
The {{Term|Systems_Engineering_Plan_(SEP)_(glossary)|System Engineering Plan (SEP)}} is, or should be, the highest-level plan for managing the Systems Engineering effort and the technical aspects of a project or program. It defines how a project will be organized and conducted in terms of both performing and controlling the Systems Engineering activities needed to address a project's system requirements and technical content. It can have a number of secondary technical plans that provide details on specific technical areas and supporting processes, procedures, tools. Also, see the [[Planning]] article in Part 3, which includes a section on [[Planning#SE Planning Process Overview|Systems Engineering Planning Process Overview]]. <br />
<br />
In United States DoD acquisition programs, the System Engineering Plan (SEP) is a Government produced document which assists in the development, communication, and management of the overall systems engineering (SE) approach that guides all technical activities of the program. It provides direction to developers for program execution. The developer uses the SEP as guidance for producing the System Engineering Management Plan (SEMP), which is a separate document and usually a contract deliverable that aligns with the SEP. As the SEP is a Government produced and maintained document and the SEMP is a developer/contractor developed and maintained document, the SEMP is typically a standalone, coordinated document. <br />
<br />
The following SEP outline from (ODASD 2011) serves as an example.<br />
<br />
#'''Introduction – Purpose and Update Plan'''<br />
# '''Program Technical Requirements'''<br />
## Architectures and Interface Control<br />
##Technical Certifications <br />
# '''Engineering Resources and Management'''<br />
##Technical Schedule and Schedule Risk Assessment<br />
## Engineering Resources and Cost/Schedule Reporting<br />
## Engineering and Integration Risk Management <br />
## Technical Organization <br />
## Relationships with External Technical Organizations <br />
## Technical Performance Measures and Metrics <br />
#'''Technical Activities and Products'''<br />
## Results of Previous Phase SE Activities<br />
## Planned SE Activities for the Next Phase<br />
## Requirements Development and Change Process<br />
## Technical Reviews <br />
## Configuration and Change Management Process<br />
## Design Considerations<br />
## Engineering Tools <br />
#'''Annex A – Acronyms'''<br />
<br />
SEP templates are often tailored to meet the needs of individual projects or programs by adding needed elements and modifying or deleting other elements. A systems engineering team leader typically works with other team members, the project/program manager (or management team), and other stakeholders to develop the SEP and maintain currency of the plan as a project evolves. Some organizations provide one or more SEP templates and offer guidance for developing and maintaining an SEP. Some organizations have a functional group that can provide assistance in developing the SEP.<br />
<br />
==References==<br />
===Works Cited===<br />
Bennis, W.G. and Nanus, B. 1985. ‘’Leaders: Strategies for Taking Charge.’’ New York, NY, USA: Harper & Row.<br />
<br />
Bowman 2004. ‘’Business Communication: Managing Information and Relationships.’’ Available at: https://homepages.wmich.edu/~bowman/channels.html.<br />
<br />
Burns, J.M. 1978. ‘’Leadership’’. New York, NY, USA: Harper & Row.<br />
<br />
Cavallo, K. and Brienza, D. 2006. “Emotional competence and leadership excellence at Johnson & Johnson,” ‘’The Emotional Intelligence and Leadership Study, Europe’s Journal of Psychology’’, Vol.2, No 1.<br />
<br />
Cole, M. S., H. Bruch, & B. Vogel. 2005. “Development and validation of a measure of organizational energy.” Academy of Management Best Paper Proceedings. In Weaver, K. M. (Ed.), Proceedings of the Sixty-fourth Annual Meeting of the Academy of Management (CD), ISSN 1543-8643.<br />
<br />
Conger, J.A. and R.N. Kanungo. 1988. “The empowerment process: Integrating theory and practice,” ‘’The Academy of Management Review,’’ Vol. 13, No. 3, pp. 471-482.<br />
<br />
Daniels, C. B. 2009. “Improving leadership in a technical environment: A case example of the ConITS leadership institute,” ‘’Engineering Management Journal,’’ 21, pp. 47-52.<br />
<br />
Drath, W. H., and C.J. Palus. 1994. ‘’Making Common Sense: Leadership as Meaning-Making in a Community of Practice.’’ Greensboro, NC: Center for Creative Leadership.<br />
<br />
Fairley, R.E. 2009. ‘’Managing and Leading Software Projects.’’ Hoboken, NJ, USA: John Wiley & Sons.<br />
<br />
Fiedler, F. E. 1964. “A Contingency Model of Leadership Effectiveness,” ‘’Advances in Experimental Social Psychology,’’ 1, 149–190.<br />
<br />
Flin, R. 2006. “Erosion of Managerial Resilience: From Vasa to NASA.” In Hollnagel, E. Woods, D.D., and Levenson, N. (Eds), ‘’Resilience Engineering Concepts and Precepts,’’ pp. 223-233. Aldershot: Ashgate.<br />
<br />
Franz, C. R. 1985. “User Leadership in the Systems Development Life Cycle: A Contingency Model.” ‘’Journal of Management Information Systems,’’ 2 (2), 5-25<br />
<br />
Frick, D. 2009. ‘’Seven Pillars of Servant Leadership: Practicing the Wisdom of Leading by Serving,’’ New Jersey: Paulist Press.<br />
<br />
Gardner, W.L., C.C. Cogliser, K.M. Daviss, & M.P. Dickens. 2011. “Authentic leadership: A review of the literature and research agenda.” ‘’Leadership Quarterly,’’ 22, 1120-1145<br />
<br />
Goleman D. 1998. “The emotionally competent leader.” ‘’Health Forum Journal,’’ 41(2), 38- 76<br />
<br />
Gurven, M., C. Von Rueden,, and C. Kaplan, M.L. Vie, 2013. “How Universal Is the Big Five? Testing the Five-Factor Model of Personality Variation Among Forager–Farmers in the Bolivian Amazon,” ‘’Journal of Personality and Social Psychology,’’ Vol. 104, No. 2, 354–370.<br />
<br />
Hersey, P., K.H. Blanchard, and D.E. Johnson. 2001. ‘’Management of Organisational Behaviour Leading Human Resources.’’ NJ, USA: Prentice Hall.<br />
<br />
Herzberg, F., B. Mausnek,and B. Snyderman. 1959. ‘’The Motivation to Work (Second Edition).’’ New York, New York, USA: John Wiley and Sons. <br />
<br />
House, R. J., and R.R. Mitchell 1974. “Path-goal theory of leadership.”<br />
<br />
‘’Journal of Contemporary Business,’’ 3(4), pp. 81-98.<br />
<br />
Isaac, R. G., W.J. Zerbe,, & D.C Pitt. 2001. “Leadership and motivation: The effective application of expectancy theory.” ‘’Journal of Managerial Issues,’’ 13(2), 212-226.<br />
<br />
Judge, T. A., J.Y. Bono, R. Ilies, & M.W. Gerhardt. 2002. “Personality<br />
<br />
and leadership: A qualitative and quantitative review.” ‘’Journal of Applied<br />
<br />
Psychology,’’ 87, 765–780.<br />
<br />
Keith, K. 2012. ‘’The Case for Servant-Leadership,’’ Honolulu, Hawaii: Terrace Press, Second Edition.<br />
<br />
Kolb, J. A. 1995. “Leader behaviours affecting team performance: Similarities and differences between leader/member assessments.” ‘’Journal of Business Communication,’’ 32, 233-248.<br />
<br />
Lewin, K., R. LIippit. and R.K. White. 1939. “Patterns of aggressive behavior in experimentally created social climates.” ‘’Journal of Social Psychology,’’ 10, 271-301.<br />
<br />
Lloyd-Walker, B. and D. Walker. 2011. “Authentic leadership for 21st century project delivery, ‘’International Journal of Project Management,’’ 29, pp 383-395.<br />
<br />
Sipe, J. and D. Frick. 2009. ‘’The Seven Pillars of Servant Leadership: Practicing the Wisdom of Leading by Serving. Mahwah, NJ, USA: Paulist Press.<br />
<br />
Triandis, H.C., R. Bontempo, , M.J. Villareal, M. Asai, and N. Lucca. 1988. “Individualism and collectivism: Cross-cultural perspectives on self-ingroup relationships,” ‘’Journal of Personality and Social Psychology,’’ Vol.54, No. 2. 323-338.<br />
<br />
Manz, C. C., and H.P. Sims Jr. 1989. ‘’Superleadership: Leading Others to Leave Themselves’’. New York, NY, USA: Prentice Hall Press.<br />
<br />
McCleave, E. B., and U. Capella. 2015. “A correlational analysis of frontline leaders as drivers of technical innovation in the aerospace industry based on the servant leadership theory.”<br />
<br />
‘’US Dissertation Abstracts International Section A: Humanities and Social Sciences,’’ Vol 75(8-A)(E).<br />
<br />
Marion, R., and M. Uhl-Bien. 2001. “Leadership in complex organizations,” ‘’The Leadership Quarterly,’’ 12, pp. 389–418.<br />
<br />
Maslow, A.H. 1943. “A theory of human motivation,” ‘’Psychological Review,‘’ 50 (4) 370–96.<br />
<br />
National Research Council. 1991. ‘’In The Mind's Eye,’’ Washington, D.C., USA: National Academy of Science.<br />
<br />
Nikoi, E. (Ed) 2014. ‘’Collaborative Communication Processes and Decision Making in Organizations.’’ Hershey, PA: Business Science Reference.<br />
<br />
Stogdill, R.M. 1948. “Personal factors associated with leadership: A survey of the literature.” ‘’Journal of Psychology,’’ Vol. 25.<br />
<br />
Toor, S.R. and G. Ofori. 2008. “Leadership vs. management: How they are different, and why!”<br />
<br />
‘’Journal of Leadership and Management in Engineering,’’ 8(2), 61- 71.<br />
<br />
Uhl-Bien, M., R.E. Riggio, K.B. Lowec, M.K. Carstend. 2014. “Followership theory: A review and research agenda,” ‘’Leadership Quarterly 25th Anniversary Issue, The Leadership Quarterly,’’ Volume 25, Issue 1, Pages 83–104.<br />
<br />
Valle, S., & L. Avella. 2003. “Cross-functionality and leadership of the new product development teams.” ‘’European Journal of Innovation Management,’’ 6(1), 32 – 47.<br />
<br />
Vroom, V.H. 1964. ‘’Work and Motivation.’’ New York, NY, USA: Wiley.<br />
<br />
Walumba, F.O., B.J. Avolio, W.L. Gardner, T.S. Wernsing, and S.J. Peterson, 2008 “Authentic leadership: Development and validation of a theory-based measure,” ‘’Journal of Management,’’ 34:1, pp. 89-126.<br />
<br />
Williams, C.R. and A. Reyes. 2012. ‘’Developing Systems Engineers at NASA Global Journal of Flexible Systems Management,’’ 13(3), 159–164.<br />
<br />
Yukl, G.A. 2012. ‘’Leadership in Organizations.’’ 8th Ed. Upper Saddle River, NJ, USA: Prentice Hall.<br />
<br />
===Primary References===<br />
Fairley, R.E. 2009. ‘’[[Managing and Leading Software Projects]].’’ Hoboken, NJ, USA: John Wiley & Sons. <br />
<br />
Myers, I.B., and P.B. Myers. 1995. ‘’[[Gifts Differing: Understanding Personality Type]],’’ 2nd ed. Mountain View, CA: Davies-Black Publishing under special license from CPP, Inc.<br />
<br />
Wilson, Larry. 2004. ‘’[[The Social Styles Handbook]].’’ Belgium: Nova Vista Publishing.<br />
<br />
Barrett, D.J. 2006. ‘’Leadership Communication.’’ Boston: McGraw Hill Education.<br />
Bass, B. M., & R. Bass. 2008. ‘’The Bass Handbook of Leadership: Theory, Research, and Managerial Applications.’’ New York, NY, USA: Free Press.<br />
<br />
Bennis, W. 2003. ‘’On Becoming a Leader.’’ New York, NY, USA: Perseus Publishing. <br />
<br />
Northouse, P. G. 2007. ‘’Leadership Theory and Practice.’’ (4th ed.). Thousand Oaks, CA, USA: Sage.<br />
<br />
===Additional References===<br />
Bass, B. M., & B.J. Avolio. 1994. ‘’Improving Organizational Effectiveness Through Transformational Leadership.’’ Thousand Oaks, CA, USA: Sage.<br />
<br />
Fiedler, F. E. 1964. “A contingency model of leadership effectiveness.” ‘’In L. Berkowitz (Ed.), Advances in experimental social psychology’’ (Vol. 1). New York, NY, USA: Academic Press.<br />
<br />
Lowe, K. B., K.G. Kroeck, & N. Sivasubramaniam. 1996. “Effectiveness correlates of transformational and transactional leadership: A meta-analytic review of the MLQ literature.” ‘’The Leadership Quarterly,’’ 7(3), 385-415.<br />
<br />
Pandya. K. D. 2014. “Key Competencies of Project Leader Beyond the Essential Technical Capabilities,” ‘’IUP Journal of Knowledge Management,’’ Vol. 12 Issue 4, 39-48.<br />
<br />
Ram, C., S. Drotter, and J. Noel. 2001. ‘’The Leadership Pipeline: How to Build the Leadership Powered Company.’’ San Francisco, CA, USA: Jossey-Bass (a Wiley Company).<br />
<br />
----<br />
<br />
<center>[[Diversity, Equity, and Inclusion|< Previous Article]] | [[Enabling Teams|Parent Article]] | [[Enabling Individuals|Next Article >]]</center><br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center><br />
<br />
[[Category:Part 5]][[Category:Topic]]<br />
[[Category:Enabling Teams]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=Team_Dynamics&diff=65015
Team Dynamics
2022-05-18T11:56:56Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div>----<br />
'''''Lead Authors:''''' ''Dick Fairley'', '''''Contributing Authors:''''' ''Alice Squires, Art Pyster''<br />
----<br />
A {{Term|Systems Engineering (glossary)|systems engineering}} (SE) {{Term|team (glossary)|team}} is a group of individuals who cooperatively perform a collection of SE tasks based on a shared vision and a common set of engineering objectives. Applying the practical considerations of group dynamics is essential to enabling SE teams to successfully perform SE activities. The interplay of the behaviors of humans in groups is varied, changing, and inescapable. Nevertheless, study of these behaviors has yielded valuable insight and knowledge on the dynamics of individuals within groups. The awareness and application of group dynamics is crucial to facilitating systems engineers' performance of work and achievement of their goals.<br />
<br />
The study of group dynamics was initially within the province of psychology and later within sociology. The importance of group dynamics to successful teams has led other disciplines such as business management to study and apply team dynamics.<br />
<br />
==History==<br />
<br />
The origins of the study of group dynamics began with Gustave Le Bon. Le Bon wrote ''La psychologie des fouls'' in 1895, which was translated into English as ''The Crowd: A Study of the Popular Mind'' a year later. Sigmund Freud wrote ''Group Psychology and the Analysis of the Ego'' in 1922 responding to Le Bon's work. Kurt Lewin is acknowledged as the "founder of social psychology", coining the term '''group dynamics'''. He founded the Research Center for Group Dynamics at the Massachusetts Institute of Technology in 1945, relocating in 1948 to the University of Michigan. Wilfred Bion studied group dynamics from a psychoanalytical perspective. He helped found the Tavistock Institute of Human Relations in 1947. In that same year, both the Research Center for Group Dynamics and the Tavistock Institute of Human Relations founded the journal ''Human Relations''. The study of group dynamics is now worldwide, active, and well established.<br />
<br />
==Nature of Groups==<br />
<br />
Groups are endemic to human existence and experience; humans are by nature social animals. Consequentially, an informed understanding of the nature of groups is very useful in enabling teams to perform SE. Research into group behavior reveals that the nature of a group can be described by interaction, goals, interdependence, structure, unity, and stage. (Forsyth 2010, 5-10)<br />
<br />
===Interaction===<br />
<br />
Communication (both verbal and non-verbal) among members within a group produces constantly changing and varied interactions. Group dynamics are more than the sum of the interactions between individual members; group interactions create synergistic behaviors and results. Interactions can be placed into two categories (1) socio-emotional interactions and (2) task interactions (Bales 1950, 1999).<br />
<br />
===Goals===<br />
<br />
All groups exist for the purpose of achieving one or more goals. The goals provide the basis for the group’s tasks. The tasks accomplished by the group can be categorized into activities and characterized by a Circumplex Model (McGrath 1984, 61), which establishes four quadrants, where the X-axis is ''choose'' vs. ''execute'' and the Y-axis is ''generate'' vs. ''negotiate''.<br />
<br />
===Interdependence===<br />
<br />
Interdependence is ''the state of being dependent to some degree on other people, as when one’s outcomes, actions, thoughts, feelings, and experiences are determined in whole or in part by others''. Interdependence can be categorized into five types (1) mutual, reciprocal; (2) unilateral; (3) reciprocal, unequal; (4) serial; and (5) multi-level. (Forsyth 2010, 8)<br />
<br />
===Structure===<br />
<br />
Structure includes the organization and patterned behaviors of a group. Structure can be deliberately devised and/or emergently observed. Most groups have both kinds of structures, which are evinced in the roles and norms of the group. ''The roles of leader and follower are fundamental ones in many groups, but other roles — information seeker, information giver, elaborator, procedural technician, encourager, compromiser, harmonizer — may emerge in any group'' (Benne and Sheats 1948; Forsyth 2010, 9). Norms are the rules that govern the actions of group members; norms can include both formal and informal rules.<br />
<br />
===Cohesion===<br />
<br />
The ''interpersonal forces that bind the members together in a single unit with boundaries that mark who is in the group and who is outside of it'' constitute a group’s cohesion (Dion 2000). Cohesion is an essential quality of group; it can vary from weak to strong. A team cannot perform effectively without strong group cohesion.<br />
<br />
===Stage===<br />
<br />
Groups exhibit stages of development. Being comprised of people, it is not surprising that groups collectively demonstrate the dynamics and growth of the individuals that constitute the group members. The most well-known and wide-spread model of the stages of group development was developed by Bruce Tuckman. The initial model identified the sequence of group development as (1) Forming, (2) Storming, (3) Norming, and (4) Performing (Tuckman 1965). He later added a final stage to the model: (5) Adjourning (Tuckman and Jensen 1977). While Tuckman’s model is sequential, others have observed that groups may actually recursively and iteratively progress through the different stages (Forsyth 2010, 20).<br />
<br />
==Practical Considerations==<br />
<br />
The dynamics associated with creating, nurturing, and leading a team that will successfully achieve the team's goals is important and challenging. Although psychologists and sociologists have conducted and continue to conduct research to understand team dynamics, the profession of business management has additionally sought to develop practical guidance for utilizing and applying this knowledge to foster high-performance teams. Accordingly, business management has focused its contribution to the field of team dynamics by publishing practical guidebooks to analyze the problems and focus on developing solutions to the problems of team dynamics (see Additional References). There are many consultancy firms throughout the world that assist organizations with the application of practical knowledge on team dynamics. Successful systems engineering teams would do well to not ignore, but rather take advantage of this knowledge.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Bales, R.F. 1950. ''Interaction Process Analysis: A Method for The Study of Small Groups.'' Reading, MA, USA: Addison-Wesley.<br />
<br />
Bales, R.F. 1999. ''Social Interaction Systems: Theory and Measurement.'' New Brunswick, NJ, USA: Transaction.<br />
<br />
Benne, K.D. and P. Sheats. 1948. "Functional Roles of Group Members." ''Journal of Social Issues.'' 4 (2): 41-49. Blackwell Publishing Ltd.<br />
<br />
Dion, K.L. 2000. "Group Cohesion: From 'Field of Forces' to Multidimensional Construct." ''Group Dynamics: Theory, Research, and Practice.'' 4 (1): 7-26. Washington DC, USA: American Psychological Association.<br />
<br />
Forsyth, D.R. 2010. ''Group Dynamics,'' 5th edition. Belmont, CA, USA: Wadsworth, Cengage Learning.<br />
<br />
McGrath, J.E. 1984. ''Groups: Interaction and Performance.'' Upper Saddle River, NJ, USA: Prentice Hall.<br />
<br />
Tuckman, B.W. 1965. "Developmental Sequence in Small Groups." ''Psychological Bulletin.'' 63 (6):384-399. Washington DC, USA: American Psychological Association.<br />
<br />
Tuckman, B.W. and M.C. Jensen. 1977. "Stages of Small Group Development Revisited." ''Group and Organization Management'' 2 (4): 419-427. Thousand Oaks, CA, USA: Sage Publications.<br />
<br />
===Primary References===<br />
<br />
Forsyth, D.R. 2010. ''[[Group Dynamics]],'' 5th edition. Belmont, CA, USA: Wadsworth, Cengage Learning.<br />
<br />
===Additional References===<br />
Scholtes, P.R., B.L. Joiner, and B.J. Streibel. 2003. ''The Team Handbook,'' 3rd edition. Edison, NJ, USA: Oriel Inc.<br />
<br />
Larson, C.E. and F.M.J. LaFaso. 1989. ''Teamwork: What Must Go Right, What Can Go Wrong.'' Newbury Park, CA, USA: Sage Publications, Inc.<br />
<br />
Lencioni, P. 2002. ''The Five Dysfunctions of a Team: A Leadership Fable''. San Francisco, CA, USA: Jossey-Bass.<br />
<br />
Lencioni, P. 2005. ''Overcoming the Five Dysfunctions of a Team.'' San Francisco, CA, USA: Jossey-Bass.<br />
<br />
McShane, S.L. and M.A. Von Glinow. 2010. ''Organizational Behavior: Emerging Knowledge and Practice for the Real World.'' New York, NY, USA: McGraw-Hill/Irwin.<br />
<br />
----<br />
<center>[[Team Capability|< Previous Article]] | [[Enabling Teams|Parent Article]] | [[Diversity, Equity, and Inclusion|Next Article >]]</center><br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center><br />
<br />
[[Category:Part 5]][[Category:Topic]]<br />
[[Category:Enabling Teams]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=Healthcare_Systems_Engineering&diff=65014
Healthcare Systems Engineering
2022-05-18T10:00:57Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div>This article provides an overview of the role of systems engineering in the engineering or re-engineering of {{Term|Healthcare (glossary)|healthcare}} systems to meet a number of modern day challenges. The role of SE in medical devices, healthcare IT, pharmaceuticals, and public health systems are considered and contrasted to "traditional" SE practices discussed elsewhere in the SEBoK. See [[Overview of the Healthcare Sector]] for details of the stakeholders and constraints of the these different parts of the sector.<br />
<br />
==Topics==<br />
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics: <br />
*[[Overview of the Healthcare Sector]]<br />
*[[Systems Engineering in Healthcare Delivery]]<br />
*[[Systems Biology]]<br />
*[[Lean in Healthcare]]<br />
<br />
==Healthcare and Systems Engineering==<br />
{{Term|Healthcare (glossary)|Healthcare}} today faces many challenges related to safety (e.g. Hospital Safety Score 2013, Andel et al. 2012, Institute of Medicine 1999), affordability, access, and the means for reliably producing positive outcomes for all patients of all ages and across all care environments. Furthermore, the health of individuals is challenged by many threats such as environmental and behavioral norms, emerging natural infectious diseases, and acute and chronic conditions that are becoming more prevalent because of longer lifespans. Re-engineering today’s healthcare to address these challenges requires a systems approach – an approach that develops solutions to contend with the complexity of healthcare-related policy, economics, social dynamics, and technology. Systems Engineers are trained to grapple with this kind of complexity by thinking holistically and to work with trans-disciplinary teams to develop solutions making re-engineering healthcare a natural fit for systems engineers and the tools of systems engineering.<br />
<br />
The disciplines involved in re-engineering healthcare are far reaching across academia, government, industry, private, and public sectors including the patients and families the healthcare field serves. Systems Engineers involved in this re-engineering draw on several tools when working with these stakeholders to develop solutions. In doing so they follow the general systems principles described in the [[Systems Approach Applied to Engineered Systems]] knowledge area in SEBoK [[Foundations of Systems Engineering|Part 2]]. First, with so many diverse {{Term|Stakeholder (glossary)|stakeholders}} involved in this field, it is vitally important for the Systems Engineer to help clarify the problem or opportunity and to conceive of the objective of the re-engineering. They need to “envision the solution” without being entirely prescriptive of the solution’s specific implementation, see [[Identifying and Understanding Problems and Opportunities]]. Then, drawing from best practices, the Systems Engineer guides the stakeholders through the [[Synthesizing Possible Solutions|synthesis of possible solutions]] and the [[Analysis and Selection between Alternative Solutions|analysis and selection between alternatives]]. Systems engineers are also involved in the [[Implementing and Proving a Solution|implementation and testing]] and the [[Deploying, Using, and Sustaining Systems to Solve Problems|deployment, use and sustainment]] of healthcare systems to provide stakeholder value. The systems approach in healthcare must be particularly mindful to not exclusively focused on technical aspects of the effort since the solutions to healthcare’s challenges exist not only in technical areas but the integration of culture, workflow and processes, with technology as a tool to support the delivery of safe, affordable, and accessible care. <br />
<br />
To achieve this system approach healthcare projects follow a version of the SE {{Term|Life Cycle (glossary)|life cycle}} described in SEBoK [[Systems Engineering and Management|Part 3]]. This included the creation of {{Term|Stakeholder Requirement (glossary)|Stakeholder}} and {{Term|System Requirement (glossary)|System}} Requirements, Systems {{Term|Architecture (glossary)|Architecture}} and {{Term|Design (glossary)|Design}} and System {{Term|Integration (glossary)|Integration}}, {{Term|Verification (glossary)|Verification}} and {{Term|Validation (glossary)|Validation}}. The SE life cycle extends to include [[System Deployment]], Operation, {{Term|Maintenance (glossary)|Maintenance}} and {{Term|Logistics (glossary)|Logistics}}. Healthcare project will also follow some of the [[Systems Engineering Management]] processes described in Part 3.<br />
<br />
It is vitally important for the healthcare systems engineer to ensure socio-technical integration and interoperability among system components are part of any project – the last thing healthcare needs is another standalone innovation that perpetuates the silos that exist in the field today. Remaining focused on the objective and problem to solve, managing scope creep, disciplined design, implementation, and project management are key activities the Systems Engineer is responsible for in {{Term|Healthcare Systems Engineering (glossary)|healthcare systems engineering}}. <br />
<br />
== Systems Engineering for Medical Device Development ==<br />
Systems Engineering for medical device development is essentially an application of [[Product Systems Engineering]] as described in SEBoK [[Applications of Systems Engineering|Part 4]] with a few customizations:<br />
* The life cycle has to comply with specific healthcare regulations, which constrain aspects of the life cycle, as exemplified by FDA regulations in the US (21CFR 820.30)<br />
* The products are market driven, with little customization allowed by the manufacturer at the customer site<br />
* The markets are midsized, with the market for a given technology or product line often being in the $1-10B range<br />
* Medical device development programs are mid-sized…many from 10-100 man-years of development, lasting 1-2 years<br />
* Time to market is critical, with the first mover or first with a complete solution capturing the majority of the profits<br />
* Most products are cyber-physical, with software becoming a larger part of the product. Many products include significant aspects of physiology or chemistry<br />
* There is a special tension between “efficacy” and “safety”. Efficacy requires the vast majority to be helped. Safety is compromised if only a very small minority is adversely affected. Truly safe systems require a special approach to systems engineering . (Leveson 2011)<br />
* Customer feedback may be constrained by safety issues as well as HIPAA regulations<br />
<br />
=== Device Development in a Market Environment ===<br />
One critical difference between many “traditional” systems engineering industries (defense and aerospace) and healthcare device development is that most healthcare device development is market driven, rather than contract driven. Some key differences between market and contract systems engineering:<br />
* The program size (budget) and dates are not ‘fixed’, they are set by the business leadership designed to maximize return on investment across a portfolio of product programs<br />
* Program scope and requirements are not fixed externally; they can be changed fairly rapidly by negotiation between functions and the executive committee.<br />
* The goal for the product development isn’t necessarily a feature set, it is a market share and price premium relative to the competition…which can be a moving target. A competitive announcement will often force a change in the program scope<br />
* In a contract based program there is an identified customer, with a set of applications and workflows. In a market driven program the workflow and use cases are defined by the developer, and the buyer needs to ‘own’ the integration of the offering into their specific systems and workflows.<br />
* For specific medical products the FDA can require pre-market trials and post market studies . (FDA 2014)<br />
* The different types of healthcare reimbursement across the world (universal coverage private insurance, national single provider, national single payer, private insurance, and out of pocket) creates dramatically different market dynamics (for individuals, healthcare providers, and product developers) . (Reid 2010)<br />
<br />
=== Regulations for Medical Device Development ===<br />
As with all regulated products, there are many regulations governing the development of medical devices. The medical device industry specific regulations are primarily driven by the US (FDA), Europe (European Commission), and Canada (Health Canada). Within the US, the FDA governs medical devices primarily through 21 CFR 820.30 (Quality Systems Regulation, Subpart C Design Controls) , which contains requirements similar to ISO 13485. The sections of the Quality Systems Regulation for Design Controls can be mapped fairly directly to ISO/IEC/IEEE 15288 (2015) and the INCOSE ''SE Handbook'' (INCOSE 2015).<br />
<br />
Table 1. Comparison of Healthcare Safety Regulations with ISO/IEC/IEEE 15288 and the INCOSE ''SE Handbook''.<br />
{|<br />
<br />
|<br />
<nowiki> </nowiki>'''21CFR820.30'''<br />
<br />
|<br />
<nowiki> </nowiki>'''ISO/IEC/IEEE 15288:2015'''<br />
<br />
|<br />
<nowiki> </nowiki>'''INCOSE ''SE Handbook''''' <br />
<br />
|-<br />
|<br />
<nowiki> </nowiki>(b)<br />
<nowiki> </nowiki> Design and development planning<br />
<br />
|<br />
<nowiki> </nowiki>6.3.1<br />
<nowiki> </nowiki> Project Planning Process<br />
<br />
|<br />
<nowiki> </nowiki>5.1<br />
<nowiki> </nowiki> Project Planning Process <br />
<br />
|-<br />
|<br />
<nowiki> </nowiki>(c)<br />
<nowiki> </nowiki> Design input.<br />
<br />
|<br />
<nowiki> </nowiki>6.4.2<br />
<nowiki> </nowiki> Stakeholder needs and requirements definition process<br />
<nowiki> </nowiki>6.4.3 Systems requirements definition process<br />
<br />
|<br />
<nowiki> </nowiki>4.2<br />
<nowiki> </nowiki> Stakeholder needs and requirements definition process<br />
<nowiki> </nowiki>4.3 Systems requirements definition process <br />
<br />
|-<br />
|<br />
<nowiki> </nowiki>(d)<br />
<nowiki> </nowiki> Design output<br />
<br />
|<br />
<nowiki> </nowiki>6.4.5<br />
<nowiki> </nowiki> Design definition process<br />
<nowiki> </nowiki>6.4.7 Implementation process<br />
<br />
|<br />
<nowiki> </nowiki>4.5<br />
<nowiki> </nowiki> Design definition process<br />
<nowiki> </nowiki>4.7 Implementation process <br />
<br />
|-<br />
|<br />
<nowiki> </nowiki>(e)<br />
<nowiki> </nowiki> Design review<br />
<br />
|<br />
<nowiki> </nowiki>6.3.2<br />
<nowiki> </nowiki> Project Assessment and Control process<br />
<br />
|<br />
<nowiki> </nowiki>5.2<br />
<nowiki> </nowiki> Project Assessment and Control process <br />
<br />
|-<br />
|<br />
<nowiki> </nowiki>(f)<br />
<nowiki> </nowiki> Design verification<br />
<br />
|<br />
<nowiki> </nowiki>6.4.9<br />
<nowiki> </nowiki> Verification Process<br />
<br />
|<br />
<nowiki> </nowiki>4.9<br />
<nowiki> </nowiki> Verification Process <br />
<br />
|-<br />
|<br />
<nowiki> </nowiki>(g)<br />
<nowiki> </nowiki> Design validation<br />
<br />
|<br />
<nowiki> </nowiki>6.4.11<br />
<nowiki> </nowiki> Validation Process<br />
<br />
|<br />
<nowiki> </nowiki>4.11<br />
<nowiki> </nowiki> Validation Process <br />
<br />
|-<br />
|<br />
<nowiki> </nowiki>(h)<br />
<nowiki> </nowiki> Design transfer<br />
<br />
|<br />
<nowiki> </nowiki>6.4.10<br />
<nowiki> </nowiki> Transition Process<br />
<br />
|<br />
<nowiki> </nowiki>4.10<br />
<nowiki> </nowiki> Transition Process <br />
<br />
|-<br />
|<br />
<nowiki> </nowiki>(i)<br />
<nowiki> </nowiki> Design changes<br />
<br />
|<br />
<nowiki> </nowiki>6.3.5<br />
<nowiki> </nowiki> Configuration Management Process<br />
<nowiki> </nowiki>6.4.13 Maintenance Process<br />
<br />
|<br />
<nowiki> </nowiki>5.5<br />
<nowiki> </nowiki> Configuration Management Process<br />
<nowiki> </nowiki>4.13 Maintenance Process <br />
<br />
|-<br />
|<br />
<nowiki> </nowiki>(j)<br />
<nowiki> </nowiki> Design history file<br />
<br />
|<br />
<nowiki> </nowiki>6.2.6<br />
<nowiki> </nowiki> Knowledge Management Process<br />
<br />
|<br />
<nowiki> </nowiki>5.6<br />
<nowiki> </nowiki> Information Management Process <br />
<br />
|}<br />
<br />
In the biomedical and healthcare environment, an important differentiator in Risk Management activities compared to other industries (see [[Risk Management]]) is that the users and patients are the center of risk analysis rather than technical or business risks. Risk management is an important element of the design control process, as preliminary hazard analysis drive initial design inputs. Traceability between identified risks, risk mitigations, design inputs, and design outputs is a key factor in product clearance through regulatory agencies. Most regulatory bodies have recognized ISO 14971: Medical devices -- Application of risk management to medical devices as a methodology for assessing and documenting product safety and effectiveness.<br />
<br />
Usability Engineering is an important subset of risk management activities. ISO 62366-1 Medical devices – Part 1: Application of usability engineering to medical devices provides a “process for a manufacturer to analyze, specify, develop and evaluate the usability of a medical device as it relates to safety. This usability engineering (human factors engineering) process permits the manufacturer to assess and mitigate risks associated with correct use and use errors, i.e., normal use.“ . (IEC 62366-2015) For example, for a device designed for home care use, there are many complex interfaces that product designers must consider. Patients may be physically or cognitively affected (age, medication, injury, etc.); they may be untrained or cared for people who are untrained; they are not professionals used to technical systems, etc. Even in the hospital setting, untrained patients may have physical access to systems. This puts a critical focus on usability and human factors considerations and the complexity of the use environment.<br />
<br />
Further, as medical devices incorporate more software and become cyber-physical devices, the regulators are also focusing on privacy and security (ISO 21827) and software life cycle management (ISO 62304).<br />
[[File:Use Cases ISO 14971 15288.png|centre|'''Figure 1 Overlap of Regulations and Standards for Medical Device Development.''' (Modified from (Malins et al. 2015). Used with Permission. All other rights are reserved by the copyright owner.)|700x700px|thumb]]<br />
<br />
Medical Device regulations, guidance, and technical standards are constantly changing, adding a complex dynamic to manage and incorporate throughout the product development life cycle.<br />
<br />
== Systems Engineering for Healthcare IT ==<br />
Systems Engineering for Healthcare Information Technology is very similar to other IT developments, with the addition of medical regulations. Healthcare Information Technology is critical to efficient flow of information and delivery of services . (Presidents Council of Advisors on Science and Technology 2010) The product development is a mix of contract driven development (with a target customer, such as healthcare.gov), and market driven (where there are more standard products, with minimal customization). Much of the market, especially for hospitals and hospital chains, is a mix of standard products with large amounts of customization to the customer’s specific needs, terminology, and workflows.<br />
<br />
== Systems Engineering for Pharmaceuticals ==<br />
The pharmaceutical industry leverages systems that include hardware, software and sometimes single-use components in different part of their value chain, for example complex analytical systems during drug discovery, complex bioreactors and downstream filtration and chromatography systems in manufacturing and drug delivery devices for the use of their drugs. These systems are subject to very different regulations, e.g. GMP or medical devices, depending on the use. One challenging aspect of these systems is that the users have different skill sets and working under different environments. And in all of the examples below, biological and/or chemical processes run on these systems, requiring deep domain knowledge of the system development teams.<br />
<br />
The in-vitro diagnostic industry also uses many systems, small devices (e.g. self-testing blood glucose or coagulation monitoring systems) all the way to large, fully automated, high throughput systems for the use in centralized laboratories. Very often, these systems operate as a closed system, so that the reagents used for the diagnostics tests, are proprietary and the vendor of the system only guarantees high quality results only when using the proprietary chemistry. This enables the vendors to often ‘place’ the instruments as highly competitive prices when the actual profit is generated through the consumables.<br />
<br />
For the chemistry part of pharma, understanding the scientific method, using a systems thinking approach, and using six sigma approaches to managing variation and interdependencies is critical. Once you create a product which includes software and physical parts (including manufacturing equipment), systems engineering of the functional design, design analysis, and integration and verification of the solution become critical.<br />
<br />
== Systems Challenges for Public Health ==<br />
Summits and inquiries into problems or shortcomings in the public health space have consistently uncovered the same issues: systemic failures in the way that public health is approached that make it nearly impossible to adequately respond to major health events. Examples can be seen from the US response to Hurricane Katrina (e.g. The White House 2006), the 2011 Thoku tsunami (e.g. Carafano 2011, The Heritage Foundation 2012), or even the 2014-2015 Ebola outbreak in West Africa (e.g. GHTC 2015).<br />
<br />
The White House report provides insights into just a few of potential challenges for the health aspects of disasters or large-scale emergencies (2006, Chapter 6):<br />
* Tens of thousands of people may require medical care.<br />
* Large portions of a population with chronic medical conditions may themselves without access to their usual medications and sources of medical care. <br />
* Hospitals and other healthcare facilities may be totally destroyed or otherwise rendered inoperable and the area’s health care infrastructure may sustain extraordinary damage.<br />
The types of public health challenges will also change over time: Immediate challenges include the identification, triage and treatment of acutely sick and injured patients; the management of chronic medical conditions in large numbers of evacuees with special health care needs; the assessment, communication and mitigation of public health risk; and the provision of assistance to State and local health officials to quickly reestablish health care delivery systems and public health infrastructures. (The White House 2006) As time passes, longer-term infectious disease outbreaks may occur or environmental impacts may cause health risks (e.g. Fukushima nuclear meltdown after the 2010 tsunami). And over time, the public health and overall healthcare infrastructure must be re-established and repaired.<br />
<br />
But the public health “system” in most countries, as currently structured, is not prepared to deal with these types of challenges. In talking about the US, Salinsky and Gursky state, “Despite recent attention to the biodefense role of public health, policymakers have not developed a clear, realistic vision for the structure and functionality of the governmental public health system. Lack of leadership and organizational disconnects across levels of government have prevented strategic alignment of resources and undermined momentum for meaningful change. A transformed public health system is needed to address the demands of emergency preparedness and health protection. … The future public health system cannot afford to be dictated by outmoded tools, unworkable structures, and outdated staffing models.” (2006)<br />
<br />
The framing of the challenge as a systems one requires the application of a systems approach, and the use of tools capable of supporting systems views, to enable better understanding of the challenges for public health and for creating ways to address these challenges. The SEBoK knowledge areas on [[Enterprise Systems Engineering]] and [[Systems of Systems (SoS)]] at least partially consider some of these challenges from a systems engineering perspective.<br />
<br />
== Systems Biology for Healthcare ==<br />
As systems science is a foundation for system engineering, systems biology is becoming recognized as a foundational discipline for healthcare systems engineering. Systems biology is an emerging discipline and is recognized as strategically important when tackling complex healthcare problems. The development of systems biology is also an emerging environment for systems engineers.<br />
<br />
According to Harvard University, “Systems biology is the study of systems of biological components, which may be molecules, cells, organisms or entire species. Living systems are dynamic and complex and their behavior may be hard to predict from the properties of individual parts. To study them, we use quantitative measurements of the behavior of groups of interacting components, systematic measurement technologies such as genomics, bioinformatics and proteomics, and mathematical and computational models to describe and predict dynamical behavior. Systems problems are emerging as central to all areas of biology and medicine.” (Harvard University 2010)<br />
<br />
As systems biology matures, its integration into healthcare approaches is expected to lead to advanced practices such as personalized and connected healthcare and the resolution of complex diseases.<br />
<br />
== Conclusion ==<br />
While systems engineering practices apply to the healthcare domain, they face different challenges than other industries and need to be tailored. In fact, different segments of the healthcare industry can take significantly different approaches to effective systems engineering and systems thinking.<br />
<br />
==References==<br />
<br />
=== Works Cited ===<br />
21 CFR 820.30. “Part 820 – Quality System Regulation: Subpart C – Design Controls.” ''Title 21 – Food and Drugs: Chapter I – Food and Drug Administration, Department of Health and Human Services: Subchapter H – Medical Devices''. Available at: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfCFR/CFRSearch.cfm?fr=820.30<br />
<br />
Andel, C., S.L. Davidow, M. Hollander, D.A. Moreno. 2012. “The economics of health care quality and medical errors.” ''Journal of Health Care Finance''. 39(1):39:50. Abstract available at: http://www.ncbi.nlm.nih.gov/pubmed/23155743 200,000 Americans die from preventable medical errors including facility-acquired conditions and millions may experience errors. In 2008, medical errors cost the United States $19.5 billion.<br />
<br />
Carafono, J.J. 2011. ''The Great Eastern Japan Earthquake: Assessing Disaster Response and Lessons for the U.S.'' Washington, DC: The Heritage Foundation. Special Report #94 for Japan. May 25, 2011.<br />
<br />
FDA. 2014. “Premarket Approval (PMA)”. Washington, DC: U.S. Food and Drug Administration (FDA). Accessed February 17, 2016. Available at: http://www.fda.gov/Medicaldevices/Deviceregulationandguidance/Howtomarketyourdevice/Premarketsubmissions/Premarketapprovalpma/Default.Htm<br />
<br />
GHTC. 2015. “Will We Learn from the Lessons of the Ebola Outbreak?” 2015 Policy Report. Washington, DC: Global Health Technologies Coalition (GHTC).<br />
<br />
Gursky, E. 2005. ''Epidemic Proportions: Building National Public Health Capabilities to Meeting National Security Threats''. Arlington, VA: Analytic Services Inc. (ANSER).<br />
<br />
Harvard University. 2010. “Department of Systems Biology.” Cambridge, MA: Harvard University. Accessed February 17, 2016. Available at: https://sysbio.med.harvard.edu/ <br />
<br />
Hospital Safety Score. 2013. “Hospital Errors are the Third Leading Cause of Death in U.S., and New Hospital Safety Scores Show Improvements are Too Slow.” Washington, DC: The LeapFrog Group. Accessed February 17, 2016. Available at: http://www.hospitalsafetyscore.org/newsroom/display/hospitalerrors-thirdleading-causeofdeathinus-improvementstooslow<br />
<br />
IEC. 2015. ''Medical devices – Part 1: Application of usability engineering to medical devices''. Geneva, Switzerland: International Electrotechnical Commissions. IEC 62366-1:2015. Available at: http://www.iso.org/iso/catalogue_detail.htm?csnumber=63179<br />
<br />
INCOSE. 2015. “Section 8.2.2.” ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities'', version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0<br />
<br />
Institute of Medicine. 1999. ''To Err is Human: Building a Safe Health System''. Washington, DC: The National Academy Press, The National Academy of Sciences. Novermber 1999. Available at: https://iom.nationalacademies.org/~/media/Files/Report%20Files/1999/To-Err-is-Human/To%20Err%20is%20Human%201999%20%20report%20brief.pdf <br />
<br />
ISO/IEC/IEEE. 2015. ''Systems and Software Engineering -- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.<br />
<br />
Leveson, N.G. 2011. ''Engineering a Safer World: Systems Thinking Applied to Safety''. Cambridge, MA: Massachusetts Institute of Technology (MIT).<br />
<br />
Presidential Council of Advisors on Science and Technology. 2010. ''Report to the President: Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward''. Washington, DC: Presidential Council of Advisors on Science and Technology, The White House. December 2010. Available at: https://www.whitehouse.gov/sites/default/files/microsites/ostp/pcast-health-it-report.pdf.<br />
<br />
Reid, T.R. 2010. ''The Healing of America: A Global Quest for Better, Cheaper, and Fairer Health Care''. New York, NY: Penguin Books.<br />
<br />
Salinsky, E. and E. Gursky. 2006. “The Case for Transforming Governmental Public Health.” ''Health Affairs''. 25(4). 1017-2018. Available at: http://content.healthaffairs.org/content/25/4/1017.full<br />
<br />
The Heritage Foundation. 2012. ''One Year Later: Lessons from Recover After the Great Eastern Japan Earthquake''. Washington, DC: The Heritage Foundation. Special Report #108 on Asia and the Pacific. April 26, 2012.<br />
<br />
The White House. 2006. ''The Federal Response to Hurricane Katrina Lessons Learned''. Washington, DC: The White House. February 2006. Available at http://library.stmarytx.edu/acadlib/edocs/katrinawh.pdf<br />
<br />
=== Primary References ===<br />
None.<br />
<br />
=== Additional References ===<br />
None.<br />
<br />
----<br />
<center>[[Mission Engineering|< Previous Article]] | [[ Applications of Systems Engineering|Parent Article]] | [[Overview of the Healthcare Sector|Next Article >]]</center><br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center><br />
<br />
[[Category:Part 4]]<br />
[[Category:Topic]]<br />
[[Category:Healthcare Systems Engineering]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=Mission_Engineering&diff=65013
Mission Engineering
2022-05-18T10:00:08Z
<p>Mhaas: </p>
<hr />
<div>----<br />
'''''Lead Author:''' Ron Giachetti,'' '''''Contributing Author: '''Andy Hernandez''.<br />
----<br />
<br />
This article describes the emerging concept of mission engineering, especially as it is being practiced by the US Department of Defense. Mission engineering is closely associated with systems of systems (SoS) because most missions are accomplished through the coordination and interoperability of multiple systems. The article defines mission engineering and describes the systems engineering activities involved in mission engineering. <br />
<br />
==Definition of Mission Engineering==<br />
{{Term|Mission_Engineering_(glossary)|Mission engineering}} describes the application of systems engineering to the planning, analysis, and designing of missions, where the mission is the system of interest. Mission engineering analyzes the mission goals and thread, analyzes the available as well as emerging operational and system capabilities, and designs a mission architecture to achieve the mission goal (Gold, 2016). Consequently, mission engineering must simultaneously consider operational, technical, and acquisition issues and their integration in order to design a solution to achieve the mission goal (Van Bossuyt et al. 2019). Lastly, the term “mission” is generally used in the military context, and most mission engineering is for military systems. However, the term, and the process and knowledge it describes, could be applied to space missions or other mission areas.<br />
<br />
Missions are almost always conducted by multiple systems coordinating their actions and sharing data. We call these mission-oriented system-of-systems (SoS). Ideally the mission-oriented SoS could be rapidly conceived, assembled, and deployed by operational commanders to react to immediate threats.<br />
<br />
==Definitions and Principles==<br />
A mission describes what the system will do and the purpose of doing it. The mission statement describes Kipling’s “six honest serving-men” – who, what, when, where, why, and sometimes how (Kipling 1902). The mission provides the context for defining measures of effectiveness and for development of the Concept of Operations (CONOPS).<br />
<br />
The mission is accomplished by operational nodes completing one or more operational activities. An operational node can be an organization, individual, or system. Operational activities are actions that either transform one or more inputs into outputs or change the state of the system. A system provides capabilities through the execution of operational activities.<br />
<br />
==Mission Engineering Activities==<br />
The following are the main activities of mission engineering:<br />
<br />
'''Mission Capability Analysis and Definition''' – The engineer analyzes the problem scenario to determine what capabilities are required and to develop a CONOPS for the mission.<br />
<br />
'''Mission Thread Definition''' – The engineer analyzes the end-to-end set of operational activities. The starting point is modeling the operational activities, their sequencing, and the information flows between them. For military systems, the mission thread is often a kill chain describing the sequence of activities from searching for a threat to engaging a threat. <br />
<br />
'''Tradeoff Analysis''' – The engineer develops alternatives for accomplishing the mission and conducts trade studies to determine the best alternative given resources and time available.<br />
<br />
'''Mission Architecting''' – The engineer develops an operational architecture describing the capabilities, the operational activities, operational nodes, and other relevant elements to model the mission. <br />
<br />
'''Requirements Engineering''' – The engineer determines the functional and non-functional requirements from the capability analysis, CONOPS, and mission threads. The engineer allocates the requirements to the operational nodes. In many cases, the systems in the operational nodes might require engineering to fulfill the requirements.<br />
<br />
'''Interoperability Analysis''' – The interoperability between systems completing the mission must occur at both the operational and technical levels (Giachetti et al. 2019). Operational interoperability describes the ability of the systems to coordinate their activities to support completion of the mission thread. Technical interoperability describes the ability of the systems to exchange data with considerations for the timeliness and quality of the data. The interoperability analysis generates additional requirements on the systems.<br />
<br />
'''Mission-Oriented SoS Implementation''' – The mission-oriented SoS must be implemented through designing and developing new systems, modifying existing systems, and/or modifying doctrine, policies, procedures, and other non-materiel means to help achieve the mission.<br />
<br />
'''Mission Verification and Validation''' – The engineer verifies that the system as delivered satisfies the requirements and validates that the system fulfills the mission purpose and stakeholder needs.<br />
<br />
==References==<br />
===Works Cited===<br />
Beam, D.F. 2015. ''Systems engineering and integration as a foundation for mission engineering''. Monterey, CA, USA: Naval Postgraduate School.<br />
<br />
Beery, P., E. Paulo. 2019. "Application of Model-Based Systems Engineering Concepts to Support Mission Engineering." IEEE ''Systems''. 7(3): 44.<br />
<br />
Dahmann, J. Keynote Address: “Mission engineering: System of systems engineering in context.” Proceedings of the IEEE System of Systems Engineering Conference, 19–22 May 2019, Anchorage, AK, USA. <br />
<br />
Giachetti, R., S. Wangert, R. Eldred. 2019. "Interoperability analysis method for mission-oriented system of systems engineering". Proceedings of IEEE International Systems Conference (SysCon), Orlando, FL, USA, 8-11 April 2019, pp. 1-6.<br />
<br />
Gold, R. 2016. "Mission engineering." Proceedings of the 19th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, Springfield, VA, USA, 24-27 October 2016.<br />
<br />
Hutchison, N.A.C., S. Luna, W.D. Miller, H.Y. See Tao, D. Verma, G. Vesonder, and J. Wade. 2018. "Mission engineering competencies." Proceedings of the American Society for Engineering Education (ASEE) Annual Conference and Exposition, vol. 2018.<br />
<br />
Kipling, R. “The Elephant’s Child, Just So Stories”. 1902. <br />
<br />
Van Bossuyt, D.L., P. Beery, B.M. O’Halloran, A. Hernandez, E. Paulo. 2019. "The Naval Postgraduate School’s Department of Systems Engineering approach to mission engineering education through capstone projects." IEEE ''Systems'' 7(3): 38.<br />
<br />
===Primary References===<br />
Gold, R. 2016. "[[Mission Engineering (reference)|Mission engineering]]." Proceedings of the 19th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, Springfield, VA, USA, 24-27 October 2016.<br />
<br />
Hutchison, N.A.C., S. Luna, W.D. Miller, H.Y. See Tao, D. Verma, G. Vesonder, and J. Wade. 2018. "[[Mission Engineering Competencies|Mission engineering competencies]]." Proceedings of the American Society for Engineering Education (ASEE) Annual Conference and Exposition, vol. 2018.<br />
<br />
Van Bossuyt, D.L., P. Beery, B.M. O’Halloran, A. Hernandez, E. Paulo. 2019. "[[The Naval Postgraduate School’s Department of Systems Engineering Approach to Mission Engineering Education through Capstone Projects|The Naval Postgraduate School’s Department of Systems Engineering approach to mission engineering education through capstone projects]]." IEEE ''Systems'' 7(3): 38.<br />
<br />
===Additional References===<br />
None.<br />
<br />
----<br />
<br />
<center> [[Capability Engineering|< Previous Article]] | [[Systems of Systems (SoS)|Parent Article]] | [[Healthcare Systems Engineering|Next Article >]]</center><br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center><br />
<br />
[[Category:Part 3]][[Category:Concept Definition]][[Category:Topic]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=Mission_Engineering&diff=65012
Mission Engineering
2022-05-18T09:59:39Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div>----<br />
'''''Lead Author:''' Ron Giachetti,'' '''''Contributing Author: '''Andy Hernandez''.<br />
----<br />
<br />
This article describes the emerging concept of mission engineering, especially as it is being practiced by the US Department of Defense. Mission engineering is closely associated with systems of systems (SoS) because most missions are accomplished through the coordination and interoperability of multiple systems. The article defines mission engineering and describes the systems engineering activities involved in mission engineering. <br />
<br />
==Definition of Mission Engineering==<br />
{{Term|Mission_Engineering_(glossary)|Mission engineering}} describes the application of systems engineering to the planning, analysis, and designing of missions, where the mission is the system of interest. Mission engineering analyzes the mission goals and thread, analyzes the available as well as emerging operational and system capabilities, and designs a mission architecture to achieve the mission goal (Gold, 2016). Consequently, mission engineering must simultaneously consider operational, technical, and acquisition issues and their integration in order to design a solution to achieve the mission goal (Van Bossuyt et al. 2019). Lastly, the term “mission” is generally used in the military context, and most mission engineering is for military systems. However, the term, and the process and knowledge it describes, could be applied to space missions or other mission areas.<br />
<br />
Missions are almost always conducted by multiple systems coordinating their actions and sharing data. We call these mission-oriented system-of-systems (SoS). Ideally the mission-oriented SoS could be rapidly conceived, assembled, and deployed by operational commanders to react to immediate threats.<br />
<br />
==Definitions and Principles==<br />
A mission describes what the system will do and the purpose of doing it. The mission statement describes Kipling’s “six honest serving-men” – who, what, when, where, why, and sometimes how (Kipling 1902). The mission provides the context for defining measures of effectiveness and for development of the Concept of Operations (CONOPS).<br />
<br />
The mission is accomplished by operational nodes completing one or more operational activities. An operational node can be an organization, individual, or system. Operational activities are actions that either transform one or more inputs into outputs or change the state of the system. A system provides capabilities through the execution of operational activities.<br />
<br />
==Mission Engineering Activities==<br />
The following are the main activities of mission engineering:<br />
<br />
'''Mission Capability Analysis and Definition''' – The engineer analyzes the problem scenario to determine what capabilities are required and to develop a CONOPS for the mission.<br />
<br />
'''Mission Thread Definition''' – The engineer analyzes the end-to-end set of operational activities. The starting point is modeling the operational activities, their sequencing, and the information flows between them. For military systems, the mission thread is often a kill chain describing the sequence of activities from searching for a threat to engaging a threat. <br />
<br />
'''Tradeoff Analysis''' – The engineer develops alternatives for accomplishing the mission and conducts trade studies to determine the best alternative given resources and time available.<br />
<br />
'''Mission Architecting''' – The engineer develops an operational architecture describing the capabilities, the operational activities, operational nodes, and other relevant elements to model the mission. <br />
<br />
'''Requirements Engineering''' – The engineer determines the functional and non-functional requirements from the capability analysis, CONOPS, and mission threads. The engineer allocates the requirements to the operational nodes. In many cases, the systems in the operational nodes might require engineering to fulfill the requirements.<br />
<br />
'''Interoperability Analysis''' – The interoperability between systems completing the mission must occur at both the operational and technical levels (Giachetti et al. 2019). Operational interoperability describes the ability of the systems to coordinate their activities to support completion of the mission thread. Technical interoperability describes the ability of the systems to exchange data with considerations for the timeliness and quality of the data. The interoperability analysis generates additional requirements on the systems.<br />
<br />
'''Mission-Oriented SoS Implementation''' – The mission-oriented SoS must be implemented through designing and developing new systems, modifying existing systems, and/or modifying doctrine, policies, procedures, and other non-materiel means to help achieve the mission.<br />
<br />
'''Mission Verification and Validation''' – The engineer verifies that the system as delivered satisfies the requirements and validates that the system fulfills the mission purpose and stakeholder needs.<br />
<br />
==References==<br />
===Works Cited===<br />
Beam, D.F. 2015. ''Systems engineering and integration as a foundation for mission engineering''. Monterey, CA, USA: Naval Postgraduate School.<br />
<br />
Beery, P., E. Paulo. 2019. "Application of Model-Based Systems Engineering Concepts to Support Mission Engineering." IEEE ''Systems''. 7(3): 44.<br />
<br />
Dahmann, J. Keynote Address: “Mission engineering: System of systems engineering in context.” Proceedings of the IEEE System of Systems Engineering Conference, 19–22 May 2019, Anchorage, AK, USA. <br />
<br />
Giachetti, R., S. Wangert, R. Eldred. 2019. "Interoperability analysis method for mission-oriented system of systems engineering". Proceedings of IEEE International Systems Conference (SysCon), Orlando, FL, USA, 8-11 April 2019, pp. 1-6.<br />
<br />
Gold, R. 2016. "Mission engineering." Proceedings of the 19th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, Springfield, VA, USA, 24-27 October 2016.<br />
<br />
Hutchison, N.A.C., S. Luna, W.D. Miller, H.Y. See Tao, D. Verma, G. Vesonder, and J. Wade. 2018. "Mission engineering competencies." Proceedings of the American Society for Engineering Education (ASEE) Annual Conference and Exposition, vol. 2018.<br />
<br />
Kipling, R. “The Elephant’s Child, Just So Stories”. 1902. <br />
<br />
Van Bossuyt, D.L., P. Beery, B.M. O’Halloran, A. Hernandez, E. Paulo. 2019. "The Naval Postgraduate School’s Department of Systems Engineering approach to mission engineering education through capstone projects." IEEE ''Systems'' 7(3): 38.<br />
<br />
===Primary References===<br />
Gold, R. 2016. "[[Mission Engineering (reference)|Mission engineering]]." Proceedings of the 19th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, Springfield, VA, USA, 24-27 October 2016.<br />
<br />
Hutchison, N.A.C., S. Luna, W.D. Miller, H.Y. See Tao, D. Verma, G. Vesonder, and J. Wade. 2018. "[[Mission Engineering Competencies|Mission engineering competencies]]." Proceedings of the American Society for Engineering Education (ASEE) Annual Conference and Exposition, vol. 2018.<br />
<br />
Van Bossuyt, D.L., P. Beery, B.M. O’Halloran, A. Hernandez, E. Paulo. 2019. "[[The Naval Postgraduate School’s Department of Systems Engineering Approach to Mission Engineering Education through Capstone Projects|The Naval Postgraduate School’s Department of Systems Engineering approach to mission engineering education through capstone projects]]." IEEE ''Systems'' 7(3): 38.<br />
<br />
===Additional References===<br />
None.<br />
<br />
----<br />
<br />
<center> [[Capability Engineering|< Previous Article]] | [[System of Systems (SoS)|Parent Article]] | [[Healthcare Systems Engineering|Next Article >]]</center><br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center><br />
<br />
[[Category:Part 3]][[Category:Concept Definition]][[Category:Topic]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=Capability_Engineering&diff=65011
Capability Engineering
2022-05-18T09:58:38Z
<p>Mhaas: Upd</p>
<hr />
<div>----<br />
'''''Lead Authors:''''' ''Judith Dahmann, Bud Lawson, Mike Henshaw''<br />
----<br />
{{Term|Capability (glossary)|Capability}} is increasingly being used to describe the Systems Engineering of Operational Capabilities. The INCOSE UK Capability System Engineering Guide (Kemp and Daw) built on this analysis and describes:<br />
<br />
* That Capabilities are realised through a combination of people, processes, information as well as equipment;<br />
* They are concerned with delivering outcomes, rather than outputs;<br />
* They are enduring, with capabilities being upgraded rather than replaced;The term emerged in defence in the early 2000, however the concepts go back far earlier (Checkland, 1997).<br />
* The concepts of Capability Systems Engineering have been used in Rail (Dogan, 2012) and Healthcare (Royal Academy of Engineering, 2017). <br />
is widely used across many industrial sectors and has begun to take on various specific meanings across, and even within, those sectors. Terms such as capability-based acquisition, capability engineering and management, life capability management, capability sponsor, etc. are now ubiquitous in defense and elsewhere. Henshaw et al. (2011) have identified at least eight worldviews of capability and capability engineering and concluded that the task of capability engineering is not consistently defined across the different communities.<br />
<br />
The aim of capability systems engineering is to ensure that the upgraded capability meets stakeholders needs. Good Capability Systems Engineering provides a clear line of sight from the purpose of the capability, through the operational concept and whole system design down to specific requirements and interfaces (Figure 1)<br />
<br />
[Add Figure]<br />
<br />
Capability engineering is concerned with the whole lifecycle (Figure 2); the “Fuzzy front end” of capability trade-offs, the conventional ‘V’ product lifecycle, and the “Messy in-service” support phase.<br />
<br />
[Add figure]<br />
<br />
Capability Systems Engineering uses standard SE tools, applied from the perspective of the asset owner-operators (i.e. the military user or rail transportation provider).<br />
<br />
Kemp and Daw (2014) note several differences between Capability Systems Engineering and the more traditional product Systems Engineering:<br />
* Using persuasion and influence as much as command and control to implement decisions<br />
* Building in flexibility where possible, as the capability will change.<br />
* Implementing the transition to the improved capability as both an engineering and cultural change.<br />
* Recognising that capabilities are often Complex Adaptive Systems. As the capability improves, users or competitors change their behaviour, reducing the effectiveness of the capability<br />
* Capability trade-offs are not about simple comparisons, between similar things – often they are choices between new equipment, better training or new processes.<br />
There is a strong relationship between Capability Engineering and system of systems (SoS).. To some a Capability is a type of system/SoS, to others it is what the system/SoS does. This is explored in Henshaw et al. (2011), who describe at least eight worldviews of capability and capability engineering<br />
<br />
==Services View of SoSE==<br />
<br />
As it has been discussed throughout the [[Systems of Systems (SoS)]] knowledge area, a ‘system of systems’ is typically approached from the viewpoint of bringing together multiple systems to provide broader capability. As is discussed in [[Architecting Approaches for Systems of Systems]], the networking of the constituent systems in a SoS is often a key part of an SoS. In some circumstances, the entire content of a SoS is information and the SoS brings together multiple information systems to support the information needs of a broader community. These ‘{{Term|Information Technology (glossary)|information technology}}<br />
<br />
{{Term|Information Technology (glossary)|information technology}}<br />
<br />
{{Term|Information Technology (glossary)|information technology}}<br />
<br />
{{Term|Information Technology (glossary)|information technology}} (IT)-based’ SoSs have the same set of characteristics of other SoSs and face many of the same challenges. Currently, IT has adopted a ‘services’ view of this type of SoS and increasingly applies a International Organization for Standaradization (ISO) 20000 series (Information technology -- Service management) or Information Technology Infrastructure Library (ITIL) v. 3 (OGC 2009) based approach to the design and management of information-based SoS. <br />
A service perspective simplifies SoSE as it:<br />
<br />
* is a more natural way for users to interact with and understand a SoS,<br />
* allows designers to design specific services to meet defined performance and effectiveness targets, and<br />
* enables specific service levels to be tested and monitored through life.<br />
<br />
Although it has not been proven to be universally applicable, the services view works well in both IT and transportation SoS.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Henshaw, M., D. Kemp, P. Lister, A. Daw, A. Harding, A. Farncombe, and M. Touchin. 2011. "Capability Engineering - An Analysis of Perspectives." Presented at International Council on Systems Engineering (INCOSE) 21st International Symposium, June 20-23, 2011, Denver, CO, USA. <br />
<br />
Checkland P. and Holwell, S, 1997, Information, Systems and Information Systems: Making Sense of the Field<br />
<br />
Dogan, H., Henshaw, M. and Johnson, J., 2012. An incremental hybridisation of heterogeneous case studies to develop an ontology for Capability Engineering. In: INCOSE, ed. The 22nd Annual INCOSE International Symposium 9-12 July 2012 Rome, Italy.<br />
<br />
Royal Academy of Engineering, 2017, Engineering better care a systems approach to health and care design and continuous improvement<br />
<br />
Erl, T. 2008. ''SOA Principles of Service Design.'' Boston, MA, USA: Prentice Hall Pearson Education.<br />
<br />
Hitchins, D.K. 2003. ''Advanced Systems Thinking, Engineering and Management''. Norwood, MA, USA: Artech House, Inc.<br />
<br />
OGC (Office of Government Commerce). 2009. ''[[ITIL Lifecycle Publication Suite Books]].'' London, UK: The Stationery Office.<br />
<br />
===Primary References===<br />
Henshaw, M., D. Kemp, P. Lister, A. Daw, A. Harding, A. Farncombe, and M. Touchin. 2011. "[[Capability Engineering - An Analysis of Perspectives]]." Presented at International Council on Systems Engineering (INCOSE) 21st International Symposium, June 20-23, 2011, Denver, CO, USA.<br />
<br />
Kemp D., Daw A. 2014, INCOSE UK Capability Systems Engineering Guide<br />
<br />
===Additional References===<br />
Davies, J.K. 2011. ''Survey of Background Literature for Capability Engineering''. INCOSE UK Capability Working Group Report.<br />
<br />
----<br />
<center>[[Socio-Technical Features of Systems of Systems|< Previous Article]] | [[Systems of Systems (SoS)|Parent Article]] | [[Mission Engineering|Next Article >]]</center><br />
<br />
<center>'''SEBoK v. 2.6, released 20 May 2022'''</center><br />
<br />
[[Category:Part 4]]<br />
[[Category:Topic]]<br />
[[Category:Systems of Systems (SoS)]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=Application_of_Systems_Engineering_Standards&diff=65010
Application of Systems Engineering Standards
2022-05-18T09:54:51Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div>----<br />
'''''Lead Authors:''''' ''Bud Lawson, Heidi Davidz'', '''''Contributing Authors:''''' ''Garry Roedler''<br />
----<br />
There are many systems engineering standards that have evolved over time, as indicated in [[Relevant Standards]]. In particular, there are standards that can have an influence on organizations and their projects as indicated in Figure 1 (below). Some pitfalls and good practices in utilizing standards are also identified in the article on relevant standards. In this article, several additional factors related to the utilization of the standards in systems engineering (SE) are presented.<br />
<br />
==Standards and their Utilization==<br />
A standard is an agreed upon, repeatable way of doing something. It is a published document that contains a technical specification or other precise criteria designed to be used consistently as a rule, guideline, or definition. Standards help to make life simpler and to increase the reliability and the effectiveness of many goods and services we use. Standards are created by bringing together the experience and expertise of all interested parties, such as the producers, sellers, buyers, users, and regulators of a particular material, product, process, or service.<br />
<br />
[[File:Potential_Standards_Influence_of_Organization_and_Project_Processes.PNG|thumb|center|800px|'''Figure 1. Potential Standards Influence of Organization and Project Processes (Adapted from Roedler 2011).''' Reprinted with permission of Garry Roedler. All other rights are reserved by the copyright owner.]]<br />
<br />
Standards are designed for voluntary use and do not impose any regulations. However, laws and regulations may address certain standards and may make compliance with them compulsory.<br />
<br />
Further, organizations and their enterprises may choose to use standards as a means of providing uniformity in their operations and/or the products and services that they produce. The standard becomes a part of the corporate culture. In this regard, it is interesting to note that the ISO/IEC/15288 15288 (2015) standard has provided such guidance and has provided a strong framework for systems engineers as well as systems engineering and business management, as forecast earlier by Arnold and Lawson (2004).<br />
<br />
[http://www.iso.org/directives ISO directives] state the following:<br />
<br />
<blockquote>''A standard does not in itself impose any obligation upon anyone to follow it. However, such an obligation may be imposed, for example, by legislation or by a contract. In order to be able to claim compliance with a standard, the user (of the standard) needs to be able to identify the requirements he is obliged to satisfy. The user needs also to be able to distinguish these requirements from other provisions where a certain freedom of choice is possible. Clear rules for the use of verbal forms (including modal auxiliaries) are therefore essential.''</blockquote><br />
<br />
==Requirements, Recommendations, and Permissions==<br />
In order to provide specificity, standards employ verb forms that convey requirements, recommendations, and permissions. For example, the ISO directives specify the following verb usages:<br />
<br />
* The word ''shall'' indicates requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted.<br />
* The word ''should'' indicates that among several possibilities, one is recommended as particularly suitable without mentioning or excluding others, or that a certain course of action is preferred, but not necessarily required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.<br />
* The word ''may'' indicates a course of action permissible within the limits of the standard.<br />
<br />
The directive also indicates that standards should avoid the use of ''will, must,'' and other imperatives.<br />
<br />
==Certification, Conformance, and Compliance==<br />
In the context of the management system standards (ISO 9001:2000 and ISO 9001:2008 or ISO 14001:2004), ''certification'' refers to the issuing of written assurance (the certificate) by an independent external body that it has audited a management system and verified that it conforms to the requirements specified in the standard.<br />
<br />
Typically, other more specific systems engineering standards are not the subject of certification. They are self-imposed in order to improve uniformity of organization and enterprise operations or to improve the quality of products and services. Alternatively, they may be dictated by legislation, policy, or as part of a formal agreement between an {{Term|Acquirer (glossary)|acquirer}} and a {{Term|Supplier (glossary)|supplier}}. <br />
<br />
Conformance testing, or type testing, is testing to determine whether a product or system meets some specified standard that has been developed for efficiency or interoperability. To aid in this, many test procedures and test setups have been developed either by the standard's maintainers or by external organizations, such as the Underwriters Laboratory (UL), specifically for testing conformity to standards.<br />
<br />
Conformance testing is often performed by external organizations, which is sometimes the standards body itself, to give greater guarantees of compliance. Products tested in such a manner are then advertised as being certified by that external organization as complying with the standard. Service providers, equipment manufacturers, and equipment suppliers rely on this data to ensure quality of service (QoS) through this conformance process.<br />
<br />
==Tailoring of Standards==<br />
Since the SE standards provide guidelines, they are most often tailored to fit the needs of organizations and their enterprises in their operations and/or for the products and services that they provide, as well as to provide agreement in a contract. Tailoring is a process described in an annex to the ISO/IEC/IEEE 15288 (2015) standard. <br />
<br />
The ISO/IEC/IEEE 15288 (2015) addresses the issues of conformance, compliance, and tailoring as follows:<br />
<br />
* Full conformance, or a claim of full conformance, first declares the set of processes for which conformance is claimed. Full conformance is achieved by demonstrating that all of the requirements of the declared set of processes have been satisfied using the outcomes as evidence.<br />
* Tailored conformance is an international standard that is used as a basis for establishing a set of processes that do not qualify for full conformance; the clauses of this international standard are selected or modified in accordance with the tailoring process. <br />
* The tailored text for which tailored conformance is claimed is declared. Tailored conformance is achieved by demonstrating that requirements for the processes, as tailored, have been satisfied using the outcomes as evidence.<br />
* When the standard is used to help develop an agreement between an acquirer and a supplier, clauses of the standard can be selected for incorporation in the agreement with or without modification. In this case, it is more appropriate for the acquirer and supplier to claim compliance with the agreement than conformance with the standard.<br />
* Any organization (e.g., a national organization, industrial association, or company) imposing the standard as a condition of trade should specify and make public the minimum set of required processes, activities, and tasks which constitute a supplier's conformance with the standard.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Arnold, S., and H. Lawson. 2004. "Viewing systems from a business management perspective." ''Systems Engineering'', 7 (3): 229.<br />
<br />
ISO. 2008. ''Quality management systems -- Requirements.'' Geneva, Switzerland: International Organisation for Standardisation. ISO 9001:2008.<br />
<br />
ISO. 2004. ''Environmental management systems -- Requirements with guidance for use.'' Geneva, Switzerland: International Organisation for Standardisation. ISO 14001:2004<br />
<br />
ISO/IEC/IEEE. 2015. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering -- System Life Cycle Processes]]''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.<br />
<br />
Roedler, G. 2010. "An Overview of ISO/IEC/IEEE 15288, System Life Cycle Processes. Asian Pacific Council on Systems Engineering." Asia-Pacific Council on Systems Engineering (APCOSE) Conference, Keelung, Taiwan.<br />
<br />
Roedler, G. 2011. "Towards Integrated Systems and Software Engineering Standards." National Defense Industrial Association (NDIA) Conference, San Diego, CA, USA.<br />
<br />
===Primary References===<br />
Roedler, G. 2010. "[[An Overview of ISO/IEC/IEEE 15288, System Life Cycle Processes]]." Proceedings of the 4th Asian Pacific Council on Systems Engineering (APCOSE) Conference, 4-6 October 2010, Keelung, Taiwan.<br />
<br />
===Additional References===<br />
None.<br />
<br />
----<br />
<br />
<center>[[Alignment and Comparison of Systems Engineering Standards|< Previous Article]] | [[Systems Engineering Standards|Parent Article]] | [[Applications of Systems Engineering|Next Article (Part 4) >]]</center><br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Systems Engineering Standards]]<br />
<center>'''SEBoK v. 2.6, released 20 May 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Relevant_Standards&diff=65009
Relevant Standards
2022-05-18T09:53:54Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div>----<br />
'''''Lead Authors:''''' ''Garry Roedler, Ken Zemrowski, Chuck Calvano'', '''''Contributing Author:''''' ''Sanford Friedenthal''<br />
----<br />
There are a multitude of standards across a number of standards development organizations (SDOs) that are related to systems engineering and systems domains. This topic examines the types of standards and provides a summary of the relevant standards for systems engineering (SE). <br />
<br />
==Standards Taxonomies and Types of Standards==<br />
There are many types of standards that focus on different aspects of SE. Thus, it can be helpful to have a taxonomy that classifies the types of standards and the objective of each type. Table 1 provides the types of the current standards and a description of the types. Refer to the [[Modeling Standards]] for a list of relevant system modeling standards.<br />
<br />
{|<br />
|+'''Table 1. Types of Systems Engineering Standards.''' (SEBoK Original)<br />
! Standard Type<br />
! Description of Type<br />
|-<br />
| Concepts and Terminology<br />
|<br />
* Defines the terminology and describes the concepts of a specific domain. <br />
|-<br />
| Process<br />
|<br />
* Elaborates a specific process, giving normative requirements for the essential elements of the process. It may give guidance to the requirements. <br />
|-<br />
| Requirements<br />
|<br />
* Describes the requirements for something. <br />
* Most often used for actions, activities, or practices and not objects (see specifications). <br />
|-<br />
| Procedure (Practice, Activity)<br />
|<br />
* A specific procedure. Instructions or requirements on how to do something. <br />
* Sometimes a description of best practices. <br />
* Sometimes guidance and sometimes normative. <br />
|-<br />
| Guidance<br />
|<br />
* Usually an interpretation and guidance of a published standard. <br />
|-<br />
| Management System<br />
|<br />
* Requirements for management. <br />
|-<br />
| Specification<br />
|<br />
* Specifies the form, attributes, or properties of a subject artifact. <br />
* Usually an object and usually normative. <br />
|-<br />
| Reference Model<br />
|<br />
* A reference model or collection of specifications of which a reference model is composed.<br />
|-<br />
| Process Reference Model (PRM)<br />
|<br />
* A collection of processes necessary and sufficient to achieve a nominated business outcome. <br />
|-<br />
| Process Assessment Model (PAM)<br />
|<br />
* Requirements and guidance for assessing attributes of nominated processes or attributes of a nominated collection of processes. <br />
|-<br />
| Guide to Body of Knowledge (BOK)<br />
|<br />
* Collection and description of the current body of knowledge in a domain, or a guide to the body of knowledge.<br />
|}<br />
<br />
==Systems Engineering Related Standards==<br />
=== Summary of Systems Engineering Related Standards===<br />
Table 2 contains a summary of SE related standards. This table does not include all SE related standards, as there are many are focused on a specific domain, sector, or user group (e.g., it does not include standards from a specific government agenda). The table does include standards that are considered to be widely applicable to systems engineering and systems life cycle management system life cycle processes, such as ISO/IEC/IEEE 15288 (2015). Where available, there is a link to the official abstract for the standard. <br />
<br />
{|<br />
|+'''Table 2. Summary of Systems Engineering Standards.''' (SEBoK Original)<br />
! Document ID<br />
! Document Title<br />
! Organization<br />
|-<br />
| [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43564 ISO/IEC/IEEE 15288]<br />
| Systems and Software Engineering - System Life Cycle Processes<br />
| ISO/IEC/IEEE<br />
|-<br />
| [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50518 ISO/IEC/IEEE 24765]<br />
| Systems and Software Engineering - Systems and Software Engineering Vocabulary<br />
| ISO/IEC/IEEE<br />
|-<br />
| [http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=50508 ISO/IEC/IEEE 42010]<br />
| Systems and Software Engineering - Architecture Description<br />
| ISO/IEC/IEEE<br />
|-<br />
| [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43693 ISO/IEC 26702] / [http://standards.ieee.org/findstds/standard/1220-2005.html IEEE 1220]<br />
| Management of the Systems Engineering Process<br />
| ISO/IEC/IEEE<br />
|-<br />
| [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=45171 ISO/IEC/IEEE 29148]<br />
| Systems and Software Engineering - Requirements Engineering<br />
| ISO/IEC/IEEE<br />
|-<br />
| [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=40723 ISO/IEC/IEEE 16085]<br />
| Systems and Software Engineering - Risk Management<br />
| ISO/IEC/IEEE<br />
|-<br />
| [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=44344 ISO/IEC/IEEE 15939]<br />
| Systems and Software Engineering - Measurement Process<br />
| ISO/IEC/IEEE<br />
|-<br />
| [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=41977 ISO/IEC/IEEE 16326]<br />
| Systems and Software Engineering - Project Management<br />
| ISO/IEC/IEEE<br />
|-<br />
| [http://infostore.saiglobal.com/store/details.aspx?ProductID=1615031 prEN9277]<br />
| Programme management - Guide for the management of Systems Engineering<br />
| CEN<br />
|-<br />
| [http://www.techstreet.com/products/1145585 EIA 632]<br />
| Engineering of a System<br />
| TechAmerica<br />
|-<br />
| [http://www.iso.org/iso/catalogue_detail?csnumber=46486 ISO 9001:2008]<br />
| Quality Management Systems - Requirements<br />
| ISO TC 176<br />
|-<br />
| [http://www.techstreet.com/products/1800866 EIA-649-B]<br />
| National Consensus Standard for Configuration Management<br />
| TechAmerica<br />
|-<br />
| [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50502 ISO/IEC/IEEE TR 24748-1]<br />
| Systems and Software Engineering - Guide to Life Cycle Management<br />
| ISO/IEC/IEEE<br />
|-<br />
| [http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=54994 ISO/IEC/IEEE TR 24748-2]<br />
| Systems and Software Engineering - Guide To The Application of ISO/IEC 15288:2008<br />
| ISO/IEC/IEEE<br />
|-<br />
| [http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=56887 ISO/IEC/IEEE CD 24748-4]<br />
| Systems and Software Engineering - Application and management of the systems engineering process<br />
| ISO/IEC/IEEE<br />
|-<br />
| [http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=56186 ISO/IEC DTR 16337]<br />
| Systems Engineering Handbook (INCOSE)<br />
| ISO/IEC/INCOSE<br />
|-<br />
| [http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=54388 ISO/IEC/IEEE 15289:2011]<br />
| Systems and Software Engineering - Content of Life-Cycle Information Products (Documentation)<br />
| ISO/IEC/IEEE<br />
|-<br />
| [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50520 ISO/IEC/IEEE 15026-1:2010]<br />
| Systems and Software Engineering - System and Software Assurance – Part 1: Concepts And Vocabulary<br />
| ISO/IEC/IEEE<br />
|-<br />
| [http://www.iso.org/iso/catalogue_detail.htm?csnumber=52926 ISO/IEC/IEEE 15026-2:2011]<br />
| Systems and Software Engineering - System and Software Assurance – Part 2: Assurance Case<br />
| ISO/IEC/IEEE<br />
|-<br />
| [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=57107 ISO/IEC/IEEE 15026-3:2011]<br />
| Systems and Software Engineering - System and Software Assurance – Part 3: Integrity Levels<br />
| ISO/IEC/IEEE<br />
|-<br />
| [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=59927 ISO/IEC/IEEE 15026-4:2012]<br />
| Systems and Software Engineering - System And Software Assurance – Part 4: Assurance in the Life Cycle<br />
| ISO/IEC/IEEE JTC 1<br />
|-<br />
| [http://www.iso.org/iso/catalogue_detail?csnumber=41553 ISO/IEC TR 90005:2008]<br />
| Guidelines for the Application of ISO 9001 to Systems Life Cycle Processes<br />
| ISO/IEC JTC 1<br />
|-<br />
| [http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=55257 ISO 10303-233:2012]<br />
| Systems Engineering Data Interchange Standard<br />
| ISO TC 184<br />
|-<br />
| [http://www.inpe.br/twiki/pub/Main/GerenciamentoProjetosEspaciais/ECSS-E-ST-10C(6March2009).pdf ECSS-E-ST-10C]<br />
| Systems Engineering General Requirements<br />
| ECSS<br />
|-<br />
| [http://www.everyspec.com/ESA/ECSS-E-10-02A_14991/ ECSS-E-ST-10-02]<br />
| Space Engineering - Verification {Note - standard is canceled}<br />
| ECSS<br />
|-<br />
| [http://www.inpe.br/twiki/pub/Main/GerenciamentoProjetosEspaciais/ECSS-E-ST-10-06C6March2009.pdf ECSS-E-ST-10-06]<br />
| Space Engineering - Technical Requirements Specification<br />
| ECSS<br />
|-<br />
| [https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCsQFjAA&url=http%3A%2F%2Fwww.ecss.nl%2Fforums%2Fecss%2Fdispatch.cgi%2Fhome%2FshowFile%2F100807%2Fd20130924080101%2FNo%2FECSS-E-ST-10-24C_DIR1(24September2013).doc&ei=Ji5cUrt0woLbBZ2qgOgN&usg=AFQjCNHNB_u3X71aMcFAeiiN2PAZuxGGmQ&bvm=bv.53899372,d.b2I ECSS-E-ST-10-24]<br />
| Space Engineering - Interface Control<br />
| ECSS<br />
|-<br />
| [http://www.everyspec.com/ESA/ECSS-M-ST-10C_REV-1_47763/ ECSS-M-ST-10]<br />
| Space Project Management - Project Planning and Implementation<br />
| ECSS<br />
|-<br />
| [http://www.ecss.nl/forums/ecss/dispatch.cgi/standards/showFile/100665/d20080802121136/No/ECSS-M-ST-80C(31July2008).doc ECSS-M-ST-40]<br />
| Space Project Management - Configuration and Information Management<br />
| ECSS<br />
|-<br />
| [http://www.everyspec.com/ESA/ecss-m-00-03a_2569/ ECSS-M-00-03]<br />
| Space Project Management - Risk Management<br />
| ECSS<br />
|-<br />
| [http://www.iso.org/iso/catalogue_detail?csnumber=43170 ISO 31000:2009]<br />
| Risk Management - Principles and Guidelines<br />
| ISO<br />
|-<br />
| [http://www.iso.org/iso/catalogue_detail?csnumber=51073 ISO 31010:2009]<br />
| Risk Management - Risk Assessment Techniques<br />
| ISO<br />
|-<br />
| [http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=33833 ISO 19439:2006]<br />
| Enterprise Integration - Framework for Enterprise Modeling<br />
| ISO<br />
|-<br />
| [http://www.iso.org/iso/catalogue_detail.htm?csnumber=28777 ISO 15704:2000]<br />
| Requirements for Enterprise - Reference Architectures and Methodologies<br />
| ISO<br />
|-<br />
| [http://www.techstreet.com/products/1854970 EIA 748]<br />
| Earned Value Management System<br />
| TechAmerica<br />
|}<br />
<br />
===Breadth and Level of Detail of Key Systems Engineering Related Standards===<br />
Figure 1 shows the level of detail and the coverage of the life cycle for some key standards or groups of standards. <br />
<br />
[[File:Breadth_and_Depth_of_Key_SE_Related_Standards.PNG|thumb|700px|center|'''Figure 1. Breadth and Depth of Key SE Related Standards (Adapted from Roedler 2011).''' Reprinted with permission of Garry Roedler. All other rights are reserved by the copyright owner.]]<br />
<br />
==Practical Considerations==<br />
Key pitfalls and good practices related to systems engineering standards are described in the next two sections.<br />
<br />
===Pitfalls===<br />
Some of the key pitfalls encountered in the selection and use of SE standards are provided in Table 3. <br />
{|<br />
|+'''Table 3. Pitfalls in Using Systems Engineering Standards.''' (SEBoK Original)<br />
! Pitfall Name<br />
! Pitfall Description<br />
|-<br />
| Turnkey Process Provision<br />
|<br />
* Expecting the standard to fully provide your SE processes without any elaboration or tailoring. <br />
|-<br />
|No Need for Knowledge<br />
|<br />
* Expecting that the standard can be used without any functional or domain knowledge since the standard is the product of collective industry knowledge. <br />
|-<br />
|No Process Integration<br />
|<br />
* Lack of integrating the standards requirements with the organization or project processes. <br />
|}<br />
<br />
===Good Practices===<br />
Some good practices as gathered from the references are provided in Table 4.<br />
{|<br />
|+'''Table 4. Good Practices in Using Systems Engineering Standards.''' (SEBoK Original)<br />
! Good Practice Name<br />
! Good Practice Description<br />
|-<br />
| Tailor for Business Needs<br />
|<br />
* Tailor the standard within conformance requirements to best meet business needs. <br />
|-<br />
|Integration into Project <br />
|<br />
*Requirements of the standard should be integrated into the project via processes or product/service requirements. <br />
|}<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
Roedler, G. 2010. "[[An Overview of ISO/IEC/IEEE 15288, System Life Cycle Processes]]." Proceedings of the 4th Asian Pacific Council on Systems Engineering (APCOSE) Conference, 4-6 October 2010, Keelung, Taiwan.<br />
<br />
Roedler, G. 2011. "Towards Integrated Systems and Software Engineering Standards." National Defense Industrial Association (NDIA) Conference, San Diego, CA, USA.<br />
<br />
===Primary References===<br />
<br />
ANSI/EIA. 2003. ''[[ANSI/EIA 632|Processes for Engineering a System]].'' Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), [[ANSI/EIA 632]]-1998. <br />
<br />
ISO/IEC/IEEE. 2015. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering -- System Life Cycle Processes]]''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.<br />
<br />
ISO/IEC/IEEE. 2009. ''[[ISO/IEC/IEEE 24765|Systems and Software Engineering - System and Software Engineering Vocabulary]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE). [[ISO/IEC/IEEE 24765]]: 2009.<br />
<br />
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 42010|Systems and software engineering - Architecture description]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), [[ISO/IEC/IEEE 42010]].<br />
<br />
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 29148|Systems and software engineering - Requirements engineering]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/Institute of Electrical and Electronics Engineers (IEEE), (IEC), [[ISO/IEC/IEEE 29148]].<br />
<br />
Roedler, G. 2010. ''[[An Overview of ISO/IEC/IEEE 15288, System Life Cycle Processes]].'' Proceedings of the 4th Asian Pacific Council on Systems Engineering (APCOSE) Conference, 4-6 October 2010, Keelung, Taiwan.<br />
<br />
===Additional References===<br />
<br />
ISO. 2003. ''Space Systems - Risk Management.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 17666:2003. <br />
<br />
ISO. 2009. ''Risk Management - Principles and Guidelines.'' Geneva, Switzerland: International Organization for Standardization (ISO), ISO 31000:2009. <br />
<br />
ISO/IEC. 2009. ''Risk Management - Risk Assessment Techniques.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 31010:2009. <br />
<br />
ISO/IEC/IEEE. 2006. ''Systems and Software Engineering - Risk Management.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 16085.<br />
<br />
ISO/IEC/IEEE. 2007. ''Systems and Software Engineering - Measurement Process.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 15939.<br />
<br />
ISO/IEC/IEEE. 2009. ''Systems and Software Engineering - Project Management.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 16326.<br />
<br />
ISO/IEC/IEEE. 2009. ''Systems and Software Engineering - System and Software Assurance, Part 1: Concepts and definitions.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 15026-1.<br />
<br />
ISO/IEC/IEEE. 2010. ''Systems and Software Engineering - System and Software Assurance, Part 2: Assurance case.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 15026-2.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and Software Engineering - Content of Life-Cycle Information Products (documentation).'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 15289.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and Software Engineering - System and Software Assurance, Part 3: Integrity Levels.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE). ISO/IEC/IEEE 15026-3.<br />
<br />
----<br />
<center>[[Systems Engineering Standards|< Previous Article]] | [[Systems Engineering Standards|Parent Article]] | [[Alignment and Comparison of Systems Engineering Standards|Next Article >]]</center><br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center><br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Systems Engineering Standards]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=Systems_Engineering_Standards&diff=65008
Systems Engineering Standards
2022-05-18T09:53:26Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div>----<br />
'''''Lead Authors:''''' ''Garry Roedler, Chuck Calvano''<br />
----<br />
This knowledge area (KA) focuses on the standards and technical protocols that are relevant to systems engineering. It looks at the types of standards, some of the key standards, and the alignment efforts to achieve a consistent set of standards. It then compares some of the standards and surveys their applications. Note that many of these standards have been used as references throughout Part 3.<br />
<br />
==Topics==<br />
Each part of the SEBoK is divided into KA's, which are groupings of information with a related theme. The KA's, in turn, are divided into topics. This KA contains the following topics: <br />
*[[Relevant Standards]]<br />
*[[Alignment and Comparison of the Standards]]<br />
*[[Application of Systems Engineering Standards]]<br />
See the article [[Matrix of Implementation Examples]] for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3.<br />
<br />
==References== <br />
None.<br />
<br />
----<br />
<center>[[System Disposal and Retirement|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[Relevant Standards|Next Article >]]</center><br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center><br />
<br />
[[Category: Part 3]][[Category:Knowledge Area]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=System_Disposal_and_Retirement&diff=65007
System Disposal and Retirement
2022-05-18T09:52:31Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div>----<br />
'''''Lead Author:''''' ''Brian Wells''<br />
----<br />
Product or service disposal and retirement is an important part of system life management. At some point, any deployed system will become one of the following: uneconomical to maintain; obsolete; or unrepairable. A comprehensive systems engineering process includes an anticipated equipment phase-out period and takes disposal into account in the design and life cycle cost assessment. (See other knowledge areas in [[Systems Engineering and Management|Part 3]] for discussion on life cycle metrics and assessment.)<br />
<br />
A public focus on sustaining a clean environment encourages contemporary systems engineering (SE) design to consider recycling, reuse, and responsible disposal techniques. (See [[Systems Engineering and Environmental Engineering]] for additional discussion.)<br />
<br />
== Topic Overview ==<br />
According to the [[INCOSE Systems Engineering Handbook]] (2012), “The purpose of the disposal process is to remove a system element from the operation environment with the intent of permanently terminating its use; and to deal with any hazardous or toxic materials or waste products in accordance with the applicable guidance, policy, regulation, and statutes." In addition to technological and economical factors, the {{Term|System-of-Interest (glossary)|system-of-interest}} (SoI) must be compatible, acceptable, and ultimately address the design of a system for the environment in terms of ecological, political, and social considerations. <br />
<br />
Ecological considerations associated with system disposal or retirement are of prime importance. The most concerning problems associated with waste management include:<br />
<br />
*Air Pollution and Control,<br />
*Water Pollution and Control,<br />
*Noise Pollution and Control,<br />
*Radiation, and<br />
*Solid Waste.<br />
<br />
In the US, the Environmental Protection Agency (EPA) and the Occupational Safety and Health Administration (OSHA) govern disposal and retirement of commercial systems. Similar organizations perform this function in other countries. OSHA addresses hazardous materials under the 1910-119A List of Highly Hazardous Chemicals, Toxics, and Reactives (OSHA 2010). System disposal and retirement spans both commercial and government developed products and services. While both the commercial and government sectors have common goals, methods differ during the disposition of materials associated with military systems.<br />
<br />
US DoD Directive 4160.21-M, ''Defense Material Disposition Manual'' (1997) outlines the requirements of the Federal Property Management Regulation (FPMR) and other laws and regulations as appropriate regarding the disposition of excess, surplus, and foreign excess personal property (FEPP). Military system disposal activities must be compliant with EPA and OSHA requirements.<br />
<br />
== Application to Product Systems ==<br />
<br />
Product system retirement may include system disposal activities or preservation activities (e.g., mothballing) if there is a chance the system may be called upon for use at a later time.<br />
<br />
[[Systems Engineering and Analysis]] has several chapters that discuss the topics of design for goals such as “green engineering,” reliability, maintainability, logistics, supportability, producibility, disposability, and sustainability. Chapter 16 provides a succinct discussion of green engineering considerations and ecology-based manufacturing. Chapter 17 discusses life cycle costing and the inclusion of system disposal and retirement costs (Blanchard and Fabrycky 2011).<br />
<br />
Some disposal of a system's components occurs during the system’s operational life. This happens when the components fail and are replaced. As a result, the tasks and resources needed to remove them from the system need to be planned well before a demand for disposal exists. <br />
<br />
Transportation of failed items, handling equipment, special training requirements for personnel, facilities, technical procedures, technical documentation updates, hazardous material (HAZMAT) remediation, all associated costs, and reclamation or salvage value for precious metals and recyclable components are important considerations during system planning. Phase-out and disposal planning addresses when disposal should take place, the economic feasibility of the disposal methods used, and what the effects on the inventory and support infrastructure, safety, environmental requirements, and impact to the environment will be (Blanchard 2010). <br />
<br />
Disposal is the least efficient and least desirable alternative for the processing of waste material (Finlayson and Herdlick 2008). <br />
<br />
The EPA collects information regarding the generation, management and final disposition of hazardous wastes regulated under the Resource Conservation and Recovery Act of 1976 (RCRA). EPA waste management regulations are codified at 40 C.F.R., parts 239-282. Regulations regarding management of hazardous wastes begin at 40 C.F.R. part 260. Most states have enacted laws and promulgated regulations that are at least as stringent as federal regulations. <br />
<br />
Due to the extensive tracking of the life of hazardous waste, the overall process has become known as the "cradle-to-grave system". Stringent bookkeeping and reporting requirements have been levied on generators, transporters, and operators of treatment, storage, and disposal facilities that handle hazardous waste.<br />
<br />
Unfortunately, disposability has a lower priority compared to other activities associated with product development. This is due to the fact that typically, the disposal process is viewed as an external activity to the entity that is in custody of the system at the time. Reasons behind this view include:<br />
<br />
*There is no direct revenue associated with the disposal process and the majority of the cost associated with the disposal process is initially hidden.<br />
*Typically, someone outside of SE performs the disposal activities. For example, neither a car manufacturer nor the car's first buyer may be concerned about a car's disposal since the car will usually be sold before disposal.<br />
<br />
The European Union’s Registration, Evaluation, Authorization, and Restriction of Chemicals (REACH) regulation requires manufacturers and importers of chemicals and products to register and disclose substances in products when specific thresholds and criteria are met (European Parliament 2007). The European Chemicals Agency (ECHA) manages REACH processes. Numerous substances will be added to the list of substances already restricted under European legislation; a new regulation emerged when the Restriction on Hazardous Substances (RoHS) in electrical and electronic equipment was adopted in 2003.<br />
<br />
Requirements for substance use and availability are changing across the globe. Identifying the use of materials in the supply chain that may face restriction is an important part of system life management. System disposal and retirement requires upfront planning and the development of a disposal plan to manage the activities. An important consideration during system retirement is the proper planning required to update the facilities needed to support the system during retirement, as explained in the ''California Department of Transportation Systems Engineering Guidebook'' (2005). <br />
<br />
Disposal needs to account for environmental and personal risks associated with the decommissioning of a system and all hazardous materials involved. The decommissioning of a nuclear power plant is a prime example of hazardous material control and exemplifies the need for properly handling and transporting residual materials resulting from the retirement of certain systems.<br />
<br />
The US Defense Logistics Agency (DLA) is the lead military agency responsible for providing guidance for worldwide reuse, recycling, and disposal of military products. A critical responsibility of the military services and defense agencies is demilitarization prior to disposal.<br />
<br />
== Application to Service Systems ==<br />
An important consideration during service system retirement or disposal is the proper continuation of services for the consumers of the system. As an existing service system is decommissioned, a plan should be adopted to bring new systems online that operate in parallel with the existing system so that service interruption is kept to a minimum. This parallel operation needs to be carefully scheduled and can occur over a significant period of time. <br />
<br />
Examples of parallel operation include phasing in new Air Traffic Control (ATC) systems (FAA 2006), the migration from analog television to new digital television modulation (FCC 2009), the transition to Internet protocol version 6 (IPv6), maintaining water handling systems, and maintaining large commercial transportation systems, such as rail and shipping vessels.<br />
<br />
The ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]]'' provides planning guidance for the retirement and replacement of large transportation systems. Chapter 4.7 identifies several factors which can shorten the useful life of a transportation system and lead to early retirement, such as the lack of proper documentation, the lack of effective configuration management processes, and the lack of an adequate operations and maintenance budget (Caltrans, and USDOT 2005).<br />
<br />
== Application to Enterprises ==<br />
The disposal and retirement of large enterprise systems requires a phased approach, with capital planning being implemented in stages. As in the case of service systems, an enterprise system's disposal and retirement require parallel operation of the replacement system along with the existing (older) system to prevent loss of functionality for the user.<br />
<br />
==Other Topics==<br />
See the OSHA standard (1996) and EPA (2010) website for references that provide listings of hazardous materials. See the [http://www.dtc.dla.mil DLA Disposal Services website] for disposal services sites and additional information on hazardous materials.<br />
<br />
== Practical Considerations ==<br />
A prime objective of systems engineering is to design a product or service such that its components can be recycled after the system has been retired. The recycling process should not cause any detrimental effects to the environment.<br />
<br />
One of the latest movements in the industry is green engineering. According to the EPA, green engineering is the design, commercialization, and use of processes and products that are technically and economically feasible while minimizing:<br />
*the generation of pollutants at the source; and<br />
*the risks to human health and the environment.<br />
<br />
See [[Environmental Engineering]] for additional information.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Blanchard, B. S. 2010. ''Logistics Engineering and Management'', 5th ed. Englewood Cliffs, NJ, USA: Prentice Hall, 341-342.<br />
<br />
Blanchard, B.S. and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' version 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
DoD. 1997. ''Defense Materiel Disposition Manual.'' Arlington, VA, USA: US Department of Defense, DoD 4160.21 -M.<br />
<br />
DLA. 2010. “Defense logistics agency disposition services.” In Defense Logistics Agency (DLA)/U.S. Department of Defense [database online]. Battle Creek, MI, USA, accessed June 19 2010: 5. Available at: http://www.dtc.dla.mil.<br />
<br />
ECHA. 2010. “European Chemicals Agency (ECHA).” In European Chemicals Agency (ECHA). Helsinki, Finland. Available at: http://echa.europa.edu/home_en.asp. <br />
<br />
EPA. 2010. “Wastes In U.S. Environmental Protection Agency (EPA)." Washington, D.C., USA. Available at: http://www.epa.gov/epawaste/index.htm.<br />
<br />
European Parliament. 2007. Regulation (EC) no 1907/2006 of the European parliament and of the council of 18 December 2006 concerning the registration, evaluation, authorisation and restriction of chemicals (REACH), establishing a European chemicals agency, amending directive 1999/45/EC and repealing council regulation (EEC) no 793/93 and commission regulation (EC) no 1488/94 as well as council directive 76/769/EEC and commission directives 91/155/EEC, 93/67/EEC, 93/105/EC and 2000/21/EC. Official Journal of the European Union 29 (5): 136/3,136/280. <br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B. and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
OSHA. 1996. “Hazardous Materials: Appendix A: List of Highly Hazardous Chemicals, Toxics and Reactives.” Washington, DC, USA: Occupational Safety and Health Administration (OSHA)/U.S. Department of Labor (DoL), 1910.119(a).<br />
<br />
''Resource Conservation and Recovery Act of 1976'', 42 U.S.C. §6901 et seq. (1976)<br />
<br />
===Primary References===<br />
Blanchard, B.S. and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' version 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook|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.<br />
<br />
Jackson, S. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science.'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R.C., D. Plakosh, and G.A. Lewis. 2003. ''[[Modernizing Legacy Systems]]: Software Technologies, Engineering Processes, and Business Practices''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
Blanchard, B. S. 2010. ''Logistics Engineering and Management'', 5th ed. Englewood Cliffs, NJ, USA: Prentice Hall, 341-342.<br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
DLA. 2010. “Defense logistics agency disposition services.” In Defense Logistics Agency (DLA)/U.S. Department of Defense [database online]. Battle Creek, MI, USA, accessed June 19 2010: 5. Available at: http://www.dtc.dla.mil.<br />
<br />
ECHA. 2010. “European Chemicals Agency (ECHA).” In European Chemicals Agency (ECHA). Helsinki, Finland. Available at: http://echa.europa.edu/home_en.asp. <br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
EPA. 2010. “Wastes In U.S. Environmental Protection Agency (EPA)." Washington, D.C., USA. Available at: http://www.epa.gov/epawaste/index.htm.<br />
<br />
European Parliament. 2007. Regulation (EC) no 1907/2006 of the European parliament and of the council of 18 December 2006 concerning the registration, evaluation, authorisation and restriction of chemicals (REACH), establishing a European chemicals agency, amending directive 1999/45/EC and repealing council regulation (EEC) no 793/93 and commission regulation (EC) no 1488/94 as well as council directive 76/769/EEC and commission directives 91/155/EEC, 93/67/EEC, 93/105/EC and 2000/21/EC. Official Journal of the European Union 29 (5): 136/3,136/280. <br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B. and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
FSA. 2010. “Template for 'System Retirement Plan' and 'System Disposal Plan'.” In Federal Student Aid (FSA)/U.S. Department of Education (DoEd). Washington, DC, USA. Accessed August 5, 2010. Available at: http://federalstudentaid.ed.gov/business/lcm.html.<br />
<br />
IEEE 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE 828. <br />
<br />
Ihii, K., C.F. Eubanks, and P. Di Marco. 1994. “Design for Product Retirement and Material Life-Cycle.” ''Materials & Design.'' 15(4): 225-33. <br />
<br />
INCOSE. 2010. “In-service systems working group.” San Diego, CA, USA: International Council on Systems Engineering (INCOSE). <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore: Institute of Engineers Singapore.<br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methodology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
Minneapolis-St. Paul Chapter of SOLE. 2003. "Systems Engineering in Systems Deployment and Retirement, presented to INCOSE." Minneapolis-St. Paul, MN, USA: International Society of Logistics (SOLE), Minneapolis-St. Paul Chapter. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C., USA: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
OSHA. 1996. “Hazardous Materials: Appendix A: List of Highly Hazardous Chemicals, Toxics and Reactives.” Washington, DC, USA: Occupational Safety and Health Administration (OSHA)/U.S. Department of Labor (DoL), 1910.119(a). <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transportation (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA, USA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
----<br />
<center>[[Capability Updates, Upgrades, and Modernization|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[Systems Engineering Standards|Next Article >]]</center><br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center><br />
<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=Capability_Updates,_Upgrades,_and_Modernization&diff=65006
Capability Updates, Upgrades, and Modernization
2022-05-18T09:51:59Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div>----<br />
'''''Lead Authors:''''' ''William Stiffler'', '''''Contributing Author:''''' ''Brian Wells''<br />
----<br />
Modernization and upgrades involve changing the product or service to include new functions and interfaces, improve system performance, and/or improve system supportability. The logistic support of a product or service reaches a point in its life where system modernization is required to resolve supportability problems and to reduce operational costs. The ''[[INCOSE Systems Engineering Handbook]]'' (INCOSE 2012) and ''[[Systems Engineering and Analysis]]'' (Blanchard and Fabrycky 2005) both stress the importance of using {{Term|Life Cycle Cost (LCC) (glossary)|life cycle costs}} (LCC) when determining if a product or service should be modernized. Systems can be modernized in the field or returned to a depot or factory for modification. <br />
<br />
Design for system modernization and upgrade is an important part of the system engineering process and should be considered as part of the early requirements and design activities. <br />
{{Term|Engineering Change Proposal (ECP) (glossary)|Engineering change proposals}} (ECPs) are used to initiate updates and modifications to the original system. Product and service upgrades can include new technology insertion, removing old equipment, or adding new equipment. {{Term|Form, Fit, Function, and Interface (F3I) (glossary)|Form, fit, function, and interface}} (F3I) is an important principle for upgrades where backward compatibility is a requirement. <br />
<br />
== Topic Overview ==<br />
Product and service modernization involves the same systems engineering (SE) processes and principles that are employed during the upfront design, development, integration, and testing. The primary differences between product and service modernization are the various constraints imposed by the existing system architecture, design, and components. Modernizing a {{Term|Legacy System (glossary)|legacy system}} requires a detailed understanding of the product or service prior to making any changes. The constraints and the existence of design and test artifacts make it necessary for the systems engineers performing modernization to tailor the traditional development processes to fit the situation.<br />
<br />
Product and service modernization occurs for many reasons, including the following:<br />
# The system or one of its subsystems is experiencing reduced performance, safety, or reliability.<br />
# A customer or other stakeholder desires a new {{Term|Capability (glossary)|capability}} for the system. <br />
# Some system components may be experiencing obsolescence, including the lack of spare parts. <br />
# New uses for the system require modification to add capabilities not built into the originally deployed system.<br />
<br />
The first three reasons above are discussed in more detail in ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook.'' (INCOSE UK Chapter 2010). <br />
<br />
The UK chapter of the INCOSE developed ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook'' (INCOSE UK Chapter 2010). This guidance document applies to any system for which multiple systems are produced. These systems may be buildings, transmission networks, aircraft, automobiles or military vehicles, trains, naval vessels, and mass transit systems.<br />
<br />
Government and military products provide a comprehensive body of knowledge for system modernization and updates. Key references have been developed by the defense industry and can be particular to their needs.<br />
<br />
Key factors and questions that must be considered by the systems engineer when making modifications and upgrades to a product or service include:<br />
* type of system (space, air, ground, maritime, and safety critical)<br />
* missions and scenarios of expected operational usage<br />
* policy and legal requirements that are imposed by certain agencies or business markets<br />
* product or service LCCs<br />
* electromagnetic spectrum usage expected, including change in RF emissions <br />
* system original equipment manufacturer (OEM) and key suppliers, and availability of parts and subsystems<br />
* understanding and documenting the functions, interfaces, and performance requirements, including environmental testing and validation<br />
* system integration challenges posed by the prevalence of system-of-systems solutions and corresponding interoperability issues between legacy, modified, and new systems<br />
* amount of regression testing to be performed on the existing software<br />
<br />
Key processes and procedures that should be considered during product and service modernization include:<br />
* legislative policy adherence review and certification<br />
* safety critical review<br />
* engineering change management and configuration control<br />
* analysis of alternatives<br />
* warranty and product return process implementation<br />
* availability of manufacturing and supplier sources and products<br />
<br />
==Application to Product Systems==<br />
Product modernization involves understanding and managing a list of product deficiencies, prioritizing change requests, and handling customer issues associated with product usage. The ''INCOSE Systems Engineering Handbook'' emphasizes the use of {{Term|Failure Modes and Effects Criticality Analysis (glossary)|Failure Modes, Effects, and Criticality Analysis}} (FMECA) to understand the root causes of product failures and provide the basis for making any product changes. <br />
<br />
Product modernization uses the engineering change management principle of change control boards to review and implement product changes and improvements. The U.S. Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics (OUSD AT&L) provides an online reference for product modernization and the use of an ECP to document planned product or service modernization efforts.<br />
<br />
Product modernization and upgrades require the use of system documentation. A key part of the product change process is to change the supporting system documentation functions, interfaces, modes, performance requirements, and limitations. Both INCOSE (2012) and Blanchard and Fabrycky (2005) stress the importance of understanding the intended usage of the product or service documented in the form of a concept of operations.<br />
<br />
If system documentation is not available, {{Term|Reverse Engineering (glossary)|reverse engineering}} is required to capture the proper “as is configuration” of the system and to gain understanding of system behavior prior to making any changes. Seacord, Plakosh, and Lewis's ''[[Modernizing Legacy Systems]]'' (2003) explains the importance of documenting the existing architecture of a system, including documenting the software architecture prior to making any changes. Chapter 5 of Seacord, Plakosh, and Lewis provides a framework for understanding and documenting a legacy system (2003). The authors point out that the product or service software will undergo a transformation during modernization and upgrades. Chapter 5 introduces a horseshoe model that includes functional transformation, code transformation, and architecture transformation (Seacord, Plakosh, and Lewis 2005).<br />
<br />
During system verification and validation (after product change), it is important to perform regression testing on the portions of the system that were not modified to confirm that upgrades did not impact the existing functions and behaviors of the system. The degree and amount of regression testing depends on the type of change made to the system and whether the upgrade includes any changes to those functions or interfaces involved with system safety. INCOSE (2012) recommends the use of a requirements verification traceability matrix to assist the systems engineer during regression testing.<br />
<br />
It is important to consider changes to the system support environment. Change may require modification or additions to the system test equipment and other support elements such as packaging and transportation.<br />
<br />
Some commercial products contain components and subsystems where modernization activities cannot be performed. An example of these types of commercial systems can be seen by looking at consumer electronics, such as radios and computer components. The purchase price of these commercial systems is low enough that upgrades are not economical and are considered cost prohibitive.<br />
<br />
==Application to Service Systems ==<br />
Service system modernization may require regulatory changes to allow the use of new technologies and new materials. Service system modernization requires backward compatibility to previous provided service capability during the period of change. Service system modernization also generally spans large geographical areas, requiring a phase-based change and implementation strategy. Transportation systems, such as highways, provide service to many different types of consumers and span large geographical areas. Modernization of transportation systems often requires reverse engineering prior to making changes to understand how traffic monitoring devices such as metering, cameras, and toll tags interface with the rest of the system. The California Department of Transportation's (CDOT's) [[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]] (2005) adds reverse engineering to the process steps for system upgrade. In addition, this reference points out the need to maintain system integrity and defines integrity to include the accurate documentation of the system's functional, performance, and physical requirements in the form of requirements, design, and support specifications.<br />
<br />
Software modernization is discussed in the ''Guide to the Software Engineering Body of Knowledge (SWEBOK)'' (Bourque and Fairley, 2014).<br />
<br />
==Application to Enterprises ==<br />
Enterprise system modernization must consider the location of the modification and the conditions under which the work will be performed. The largest challenge is implementing the changes while the system remains operational. In these cases, disruption of ongoing operations is a serious risk. For some systems, the transition between the old and new configuration is particularly important and must be carefully planned. <br />
<br />
Enterprise system modernization may require coordination of changes across international boundaries. Enterprise modifications normally occur at a lower level of the system hierarchy. Change in requirements at the system level would normally constitute a new system or a new model of a system. <br />
<br />
The ''INCOSE UK Chapter Supplementary Guidance'' (2010) discusses the change to the architecture of the system. In cases where a component is added or changed, this change will constitute a change to the architecture. As an example, the global positioning system (GPS) is an enterprise system implemented by the United States military but used by both commercial and government consumers worldwide. Modernization may involve changes to only a certain segment of the enterprise, such as the ground user segment to reduce size, weight, and power. Modernization may only occur in certain geographical areas of operation. For example, the air transportation system consists of multiple countries and governing bodies dispersed over the entire world. Changes can occur locally or can require coordination and integration world-wide.<br />
<br />
==Other Topics ==<br />
===The Vee Model for Modifications===<br />
<br />
Figure 1 below illustrates how the standard {{Term|Vee (V) Model (glossary)|Vee model}} would be applied to a system modification. This Vee model is for the entire system; the key point is that if a modification is being initiated at a lower level of the system hierarchy, the Vee model must be entered at that level as shown in the figure. The figure shows three entry points to the Vee model. As the ''INCOSE UK Chapter Supplementary Guidance'' (2010) points out, the Vee model may be entered multiple times during the life of the system.<br />
<br />
[[File:052411_BSBW_The_Vee_Model.png|thumb|600px|center|'''Figure 1. The Vee Model for Modifications at the Three Different Levels.''' (SEBoK Original)]]<br />
<br />
A change to the system that does not change the system capabilities but does change the requirements and design of a subsystem that may be introduced into the process at point B on the Vee model (see Figure 1). Changes of this type could provide a new subsystem, such as a computer system, that meets the system-level requirements but has differences from the original, which necessitates modifications to the lower-level requirements and design, such as changing disk memory to solid state memory. The process for implementing changes starting at this point has been described by Nguyen (2006). Modification introduced at points B or C (in Figure 1) necessitate flowing the requirements upward through their “parent” requirements to the system-level requirements. <br />
<br />
There are many cases where the change to a system needs to be introduced at the lowest levels of the architectural hierarchy; here, the entry point to the process is at point C on the Vee model. These cases are typically related to obsolete parts caused by changes in technology or due to reliability issues with subsystems and parts chosen for the original design. A change at this level should be F3I compatible so that none of the higher-level requirements are affected. The systems engineer must ensure there is no impact at the higher levels; when this does occur, it must be immediately identified and worked out with the customer and the other stakeholders.<br />
<br />
In “Life extension of Civil Infrastructural works - a systems engineering approach” van der Laan (2008) provides a maintenance process that interacts with the system engineering process, represented by the Vee model. His life extension (or modernization) process model includes reverse engineering to obtain the system definition necessary for the modernization process. Consideration of the total lifecycle of the system will result in the capture of all of the records necessary for later upgrade; however, for many reasons, the systems engineer will find that the necessary information has not been captured or maintained.<br />
<br />
== Practical Considerations ==<br />
As pointed out by the ''INCOSE UK Chapter Supplementary Guidance'' (2010) there may be multiple modifications to a system in its lifetime. Often these modifications occur concurrently. This situation requires special attention and there are two methods for managing it. The first is called the “block” method. This means that a group of systems are in the process of being modified simultaneously and will be deployed together as a group at a specific time. This method is meant to ensure that at the end state, all the modifications have been coordinated and integrated so there are no conflicts and no non-compliance issues with the system-level requirements. The second method is called continuous integration and is meant to occur concurrently with the block method. Information management systems provide an example of a commercial system where multiple changes can occur concurrently. The information management system hardware and network modernization will cause the system software to undergo changes. Software release management is used to coordinate the proper timing for the distribution of system software changes to end-users (Michigan Department of Information Technology, 2008).<br />
<br />
===Application of Commercial-Off-the-Shelf Components===<br />
Currently, a prominent consideration is the use of commercial-off-the-shelf (COTS) components. The application of COTS subsystems, components, and technologies to system life management provides a combination of advantages and risks. The first advantage is the inherent technological advancements that come with COTS components. COTS components continue to evolve toward a higher degree of functional integration. They provide increased functionality, while shrinking in physical size. The other advantage to using COTS components is that they typically have a lower cost. <br />
<br />
The risks associated with using COTS during system life management involve component obsolescence and changes to system interfaces. Commercial market forces drive some components to obsolescence within two years or less. Application of COTS requires careful consideration to form factor and interface (physical and electrical).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Blanchard, B.S. and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Bourque, P. and R.E. Fairley (eds.). 2014. ''Guide to the Software Engineering Body of Knowledge (SWEBOK)''. Los Alamitos, CA, USA: IEEE Computer Society. Available at: http://www.swebok.org<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' version 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook|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.<br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook,'' version 3.2, issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methodology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
OUSD(AT&L). 2012. “On-line policies, procedures, and planning references.” Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics, US Department of Defense (DoD). Accessed on August 30, 2012. Available at: http://www.acq.osd.mil/log/<br />
<br />
Seacord, R.C., D. Plakosh, and G.A. Lewis. 2003. ''[[Modernizing Legacy Systems]]: Software Technologies, Engineering Processes, and Business Practices''. Boston, MA, USA: Pearson Education.<br />
<br />
van der Laan, J. 2008. “Life extension of Civil Infrastructural works - a systems engineering approach.” Proceedings of the 18th annual International Symposium of the International Council on Systems Engineering, Utrecht, the Netherlands.<br />
<br />
===Primary References===<br />
Blanchard, B.S. and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' version 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook|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.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science.'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R.C., D. Plakosh, and G.A. Lewis. 2003. ''[[Modernizing Legacy Systems]]: Software Technologies, Engineering Processes, and Business Practices''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18. <br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B. and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
IEC. 2007. ''Obsolescence Management - Application Guide'', ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302. <br />
<br />
IEEE. 2010. ''IEEE Standard Framework for Reliability Prediction of Hardware''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE 1413.<br />
<br />
IEEE. 1998. ''IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE 1332. <br />
<br />
IEEE. 2008. ''IEEE Recommended practice on Software Reliability''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE 1633. <br />
<br />
IEEE. 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE 828. <br />
<br />
INCOSE. 2010. “In-service systems working group.” San Diego, CA, USA: International Council on Systems Engineering (INCOSE). <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook, version 3.2'', issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore. <br />
<br />
ISO/IEC. 2003. “Industrial Automation Systems Integration-Integration of Life-Cycle Data for Process Plants including Oil, Gas Production Facilities.” Geneva, Switzerland: International Organization for Standardization (ISO)/International Electro technical Commission (IEC). <br />
<br />
Jackson, S. 2007. “A Multidisciplinary Framework for Resilience to Disasters and Disruptions.” ''Journal of Design and Process Science.'' 11(2): 91-108, 110.<br />
<br />
Jackson, S. 1997. ''Systems Engineering for Commercial Aircraft.'' Surrey, UK: Ashgate Publishing, Ltd. <br />
<br />
Koopman, P. 1999. “Life Cycle Considerations.” In Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.<br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA, USA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methdology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C., USA: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
Reason, J. 1997. ''Managing the Risks of Organizational Accident.'' Aldershot, UK: Ashgate. <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transpofration (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA, USA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
----<br />
<center>[[Service Life Extension|< Previous Article]] | [[System Maintenance|Parent Article]] | [[System Disposal and Retirement|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]<br />
<center>'''SEBoK v. 2.6, released 20 May 2022'''</center></div>
Mhaas
https://sebokwiki.org/w/index.php?title=Service_Life_Extension&diff=65005
Service Life Extension
2022-05-18T09:50:58Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div>----<br />
'''''Lead Author:''''' ''William Stiffler'', '''''Contributing Author:''''' ''Brian Wells''<br />
----<br />
Product and service life extension involves continued use of a product and/or service beyond its original {{Term|Design Life (glossary)|design life}}. Product and service life extension involves assessing the risks and the {{Term|Life Cycle Cost (LCC) (glossary)|life cycle cost}} (LCC) of continuing the use of the product or service versus the cost of a replacement system.<br />
<br />
{{Term|Service Life Extension (SLE) (glossary)|Service life extension}} (SLE) emphasizes reliability upgrades and component replacement or rebuilding of the system to delay the system’s entry into ''wear-out'' status due to issues such as expensive sustainment, reliability, safety, and/or performance requirements that can no longer be met. The goal is typically to return the system to as new a condition as possible while remaining consistent with the economic constraints of the program.<br />
<br />
SLE is regarded as an environmentally friendly way to relieve rampant waste by prolonging the {{Term|Useful life (glossary)|useful life}} of retiring products and preventing them from being discarded too early when they still have unused value. However, challenged by fast-changing technology and physical deterioration, a major concern in planning a product SLE is considering to what degree a product or service is fit to have its life extended.<br />
<br />
==Topic Overview==<br />
SLE is typically required in the following circumstances:<br />
* The system no longer meets the system performance or reliability requirements.<br />
* The cost of operation and maintenance exceeds the cost of SLE, or the available budgets.<br />
* Parts are no longer available for repair and maintenance.<br />
* Operation of the system violates rules or regulations, such as environmental or safety regulations.<br />
* Parts of the system are about to reach their operations life limits, which will result in the issue listed above occurring.<br />
<br />
It is best if systems engineers use a proactive approach that predicts ahead, so that SLE can be accomplished before the system fails to meet its requirements and before the operations and support costs rise above acceptable limits.<br />
<br />
Key factors that must be considered by the systems engineer during service life extension include:<br />
* current life cycle costs of the system <br />
* design life and expected remaining useful life of the system<br />
* software maintenance<br />
* configuration management <br />
* warranty policy<br />
* availability of parts, subsystems, and manufacturing sources<br />
* availability of system documentation to support life extension<br />
<br />
System design life is a major consideration for SLE. System design life parameters are established early on during the system design phase and include key assumptions involving safety limits and material life. Safety limits and the properties of material aging are critical to defining system life extension. Jackson emphasizes the importance of architecting for system resiliency in increasing system life. He also points out that a system can be architected to withstand internal and external disruptions (2007, 91-108). Systems that age through use, such as aircraft, bridges, and nuclear power plants, require periodic inspection to ascertain the degree of aging and fatigue. The results of inspections determine the need for actions to extend the product life (Elliot, Chen, and Swanekamp 1998, sec. 6.5).<br />
<br />
Software maintenance is a critical aspect of SLE. The {{Term|Legacy System (glossary)|legacy system}} may include multiple computer resources that have been in operation for a period of many years and have essential functions that must not be disrupted during the upgrade or integration process. Typically, legacy systems include a computer resource or application software program that continues to be used because the cost of replacing or redesigning it is prohibitive. The Software Engineering Institute (SEI) has addressed the need for SLE of software products and services and provides useful guidance in the online library for Software Product Lines (SEI 2010, 1). (See [[Systems Engineering and Software Engineering]] for additional discussion of software engineering (SwE) factors to consider.)<br />
<br />
Systems engineers have found that service life can be extended through the proper selection of materials. For example, transportation system elements such as highway bridges and rail systems are being designed for extended service life by using special epoxy-coated steel (Brown, Weyers, and Spinkel 2006, 13). Diminishing manufacturing sources and diminishing suppliers need to be addressed early in the SLE process. Livingston (2010) in ''Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices'' provides a method for addressing product life extension when the sources of supply are an issue. He addresses the product life cycle model and describes a variety of methods that can be applied during system design to minimize the impact of future component obsolescence issues.<br />
<br />
During product and service life extension, it is often necessary to revisit and challenge the assumptions behind any previous life cycle cost analysis (and constituent analyses) to evaluate their continued validity and/or applicability early in the process.<br />
<br />
==Application to Product Systems==<br />
Product life extension requires an analysis of the LCC associated with continued use of the existing product versus the cost of a replacement product. In the [[INCOSE Systems Engineering Handbook]], Chapter 3.3 points out that the support stage includes service life extension (2012). Chapter 7 provides a framework to determine if a product’s life should be extended (INCOSE 2012). In [[Systems Engineering and Analysis]], Chapter 17 provides an LCC methodology and emphasizes the analysis of different alternatives before deciding on product life extension (Blanchard and Fabrycky 2011). <br />
<br />
For military systems, service life extension is considered a subset of modification or modernization. Military systems use well-developed and detailed guidance for SLE programs (SLEP). The Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics (OSD AT&L) provides an online reference for policies, procedures, planning guidance, and whitepapers for military product service life extension (DAU 2011). Continuous military system modernization is a process by which state-of-the-art technologies are inserted continuously into weapon systems to increase reliability, lower sustainment costs, and increase the war fighting capability of a military system to meet evolving customer requirements throughout an indefinite service life. <br />
<br />
Aircraft service life can be extended by reducing the dynamic loads which lead to structural fatigue. The Boeing B-52 military aircraft and the Boeing 737 commercial aircraft are prime examples of system life extension. The B-52 was first fielded in 1955 and the Boeing 737 has been fielded since 1967; both aircraft are still in use today.<br />
<br />
For nuclear reactors, system safety is the most important precondition for service life extension. System safety must be maintained while extending the service life (Paks 2010). Built-in tests, automated fault reporting and prognostics, analysis of failure modes, and the detection of early signs of wear and aging may be applied to predict the time when maintenance actions will be required to extend the service life of the product. (For additional discussion, see [[Safety Engineering]].)<br />
<br />
==Application to Service Systems==<br />
For systems that provide services to a larger consumer base, SLE involves continued delivery of the service without disrupting consumer use. This involves capital investment and financial planning, as well as a phased deployment of changes. Examples of these concepts can be seen in transportation systems, water treatment facilities, energy generation and delivery systems, and the health care industry. As new technologies are introduced, service delivery can be improved while reducing LCC's. Service systems must continuously assess delivery costs based upon the use of newer technologies. <br />
<br />
Water handling systems provide a good example of a service system that undergoes life extension. Water handling systems have been in existence since early civilization. Since water handling systems are in use as long as a site is occupied (e.g., the Roman aqueducts) and upgrades are required as the population expands, such systems are a good example of "systems that live forever." For example, there are still U.S. water systems that use a few wooden pipes since there has been no reason to replace them. Water system life extension must deal with the issue of water quality and the capacity for future users (Mays 2000). Water quality requirements can be further understood from the AWWA Manuals of Water Supply Practices (AWWA 2010).<br />
<br />
==Application to Enterprises==<br />
SLE of a large enterprise, such as the National Astronautics and Space Administration's (NASA) national space transportation system, involves SLE on the elements of the enterprise, such as the space vehicle (shuttle), ground processing systems for launch operations and mission control, and space-based communication systems that support space vehicle tracking and status monitoring. SLE of an enterprise requires a {{Term|holism (glossary)|holistic}} look across the entire enterprise. A balanced approach is required to address the cost of operating older system components versus the cost required to implement service life improvements.<br />
<br />
Large enterprise systems, such as oil and natural gas reservoirs which span broad geographical areas, can use advanced technology to increase their service life. The economic extraction of oil and natural gas resources from previously established reservoirs can extend their system life. One such life extension method is to pump special liquids or gases into the reservoir to push the remaining oil or natural gas to the surface for extraction (Office of Natural Gas & Oil Technology 1999).<br />
<br />
==Other Topics==<br />
Commercial product developers have been required to retain information for extended periods of time after the last operational product or unit leaves active service (for up to twenty years). Regulatory requirements should be considered when extending service life (INCOSE 2012).<br />
<br />
==Practical Considerations==<br />
The cost associated with life extension is one of the main inputs in the decision to extend service life of a product or a service. The cost of SLE must be compared to the cost of developing and deploying a new system, as well as the functional utility the user will obtain from each of the alternatives. It is often the case that the funding required for SLE of large complex systems is spread over several fiscal planning cycles and is therefore subject to changes in attitude by the elected officials that appropriate the funding.<br />
<br />
The challenges with upgrading a system while it is still being used, which is often the case with SLE, must be understood and planned to avoid serious disruptions to the services the systems provide.<br />
<br />
Any SLE must also consider the obsolescence of the systems parts, (e.g., software, amount of system redesign that is required to eliminate the obsolete parts, etc.).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
AWWA. 2010. “AWWA Manuals of Water Supply Practices.” In American Water Works Association (AWWA). Denver, CO. Accessed August 5, 2010. Available at: http://www.awwa.org/Resources/standards.cfm?ItemNumber=47829&navItemNumber=47834.<br />
<br />
Blanchard, B.S. and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Brown, M., R. Weyers, and M. Sprinkel. 2006. “Service Life Extension of Virginia Bridge Decks afforded by Epoxy-Coated Reinforcement.” ''Journal of ASTM International (JAI),'' 3(2): 13. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook|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.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science.'' 11(2).<br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
Office of Natural Gas and Oil Technology. 1999. ''Reservoir LIFE Extension Program: Encouraging Production of Remaining Oil and Gas.'' Washington, DC, USA: U.S. Department of Energy (DoE). <br />
<br />
Paks Nuclear Power Plant. 2010. “Paks Nuclear Power Plant: Service Life Extension.” In Paks Nuclear Power Plant, Ltd. Hungary, accessed August 5, 2010. Available at: http://paksnuclearpowerplant.com/service-life-extension.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
===Primary References===<br />
Blanchard, B.S., and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]]'', 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' version 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook|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.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science.'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R.C., D. Plakosh, and G.A. Lewis. 2003. ''[[Modernizing Legacy Systems]]: Software Technologies, Engineering Processes, and Business Practices''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
AWWA. 2010. “AWWA Manuals of Water Supply Practices.” In American Water Works Association (AWWA). Denver, CO, USA. Accessed August 5, 2010. Available at: http://www.awwa.org/Resources/standards.cfm?ItemNumber=47829&navItemNumber=47834.<br />
<br />
Blanchard, B.S. 2010. ''Logistics engineering and management'', 5th ed. Englewood Cliffs, NJ, USA: Prentice Hall, 341-342.<br />
<br />
Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18. <br />
<br />
Brown, M., R. Weyers, and M. Sprinkel. 2006. “Service Life Extension of Virginia Bridge Decks afforded by Epoxy-Coated Reinforcement.” ''Journal of ASTM International (JAI),'' 3(2): 13. <br />
<br />
Caltrans and USDOT. 2005. ''Systems engineering guidebook for ITS,'' version 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research & Innovation/U.S. Department of Transportation (USDOT), SEG for ITS 1.1: 278, 101-103, 107.<br />
<br />
Casetta, E. 2001. ''Transportation Systems Engineering: Theory and methods''. New York, NY, USA: Kluwer Publishers Academic, Springer. <br />
<br />
DAU. 2010. “Acquisition community connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” In Defense Acquisition University (DAU)/US Department of Defense (DoD). Ft. Belvoir, VA, USA, accessed August 5, 2010. https://acc.dau.mil/.<br />
<br />
DLA. 2010. “Defense logistics agency disposition services.” In Defense Logistics Agency (DLA)/U.S. Department of Defense [database online]. Battle Creek, MI, USA, accessed June 19 2010: 5. Available at: http://www.dtc.dla.mil.<br />
<br />
Elliot, T., K. Chen, and R.C. Swanekamp. 1998. "Section 6.5" in ''Standard Handbook of Powerplant Engineering.'' New York, NY, USA: McGraw Hill.<br />
<br />
FAA. 2006. "Section 4.1" in “Systems Engineering Manual.” Washington, DC, USA: US Federal Aviation Administration (FAA).<br />
<br />
FCC. 2009. “Radio and Television Broadcast Rules.” Washington, DC, USA: US Federal Communications Commission (FCC), 47 CFR Part 73, FCC Rule 09-19: 11299-11318.<br />
<br />
Finlayson, B. and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
Gehring, G., D. Lindemuth, and W.T. Young. 2004. “Break Reduction/Life extension Program for CAST and Ductile Iron Water Mains.” Paper presented at NO-DIG 2004, Conference of the North American Society for Trenchless Technology (NASTT), March 22-24, New Orleans, LA, USA. <br />
<br />
Hovinga, M.N. and G.J. Nakoneczny. 2000. “Standard Recommendations for Pressure Part Inspection during a Boiler Life Extension Program.” Paper presented at ICOLM (International Conference on Life Management and Life Extension of Power Plant), May, Xi’an, P.R. China. <br />
<br />
IEC. 2007. ''Obsolescence Management - Application Guide'', ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302. <br />
<br />
IEEE. 2010. ''IEEE Standard Framework for Reliability Prediction of Hardware''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
IEEE. 1998. ''IEEE Standard Reliability Program for the Development and Production of Electronic Systems and Equipment''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1332. <br />
<br />
IEEE. 2008. ''IEEE Recommended practice on Software Reliability''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1633. <br />
<br />
IEEE 2005. ''IEEE Standard for Software Configuration Management Plans''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 828. <br />
<br />
IEEE. 2010. IEEE Standard Framework for Reliability Prediction of Hardware. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), IEEE STD 1413.<br />
<br />
ISO/IEC/IEEE. 2015. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering -- System Life Cycle Processes]]''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.<br />
<br />
Ihii, K., C.F. Eubanks, and P. Di Marco. 1994. “Design for Product Retirement and Material Life-Cycle.” ''Materials & Design.'' 15(4): 225-33. <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook,'' version 3.2, issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. “Systems Engineering Body of Knowledge, provisional,” version 2.0. Singapore. <br />
<br />
ISO/IEC. 2003. “Industrial Automation Systems Integration-Integration of Life-Cycle Data for Process Plants including Oil, Gas Production Facilities.” Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC). <br />
<br />
ISO/IEC. 1997. “Systems Engineering for Commercial Aircraft.” Surrey, UK: Ashgate Publishing Ltd. <br />
<br />
Koopman, P. 1999. “Life Cycle Considerations.” In Carnegie-Mellon University (CMU). Pittsburgh, PA, USA, accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.<br />
<br />
L3 Communications. 2010. “Service Life Extension Program (SLEP).” Newport News, VA, USA: L3 Communications, Flight International Aviation LLC. <br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Mays, L. (ed). 2000. "Chapter 3" in ''Water Distribution Systems Handbook.'' New York, NY, USA: McGraw-Hill Book Company.<br />
<br />
MDIT. 2008. ''System Maintenance Guidebook (SMG),'' version 1.1: A companion to the systems engineering methodology (SEM) of the state unified information technology environment (SUITE). MI, USA: Michigan Department of Information Technology (MDIT), DOE G 200: 38. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C., USA: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
Office of Natural Gas and Oil Technology. 1999. ''Reservoir LIFE Extension Program: Encouraging Production of Remaining Oil and Gas.'' Washington, DC, USA: U.S. Department of Energy (DoE). <br />
<br />
Paks Nuclear Power Plant. 2010. “Paks Nuclear Power Plant: Service Life Extension.” In Paks Nuclear Power Plant, Ltd. Hungary, accessed August 5, 2010. Available at: http://paksnuclearpowerplant.com/service-life-extension.<br />
<br />
Reason, J. 1997. ''Managing the Risks of Organizational Accident.'' Aldershot, UK: Ashgate. <br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transportation (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Automotive--Maintenance and Aftermarket.” Warrendale, PA: Society of Automotive Engineers (SAE) International. <br />
<br />
Schafer, D.L. 2003. “Keeping Pace With Technology Advances When Funding Resources Are Diminished.” Paper presented at Auto Test Con. IEEE Systems Readiness Technology Conference, Anaheim, CA, USA: 584.<br />
<br />
SEI. 2010. “Software Engineering Institute.” In Software Engineering Institute (SEI)/Carnegie-Mellon University (CMU). Pittsburgh, PA, accessed August 5, 2010. http://www.sei.cmu.edu.<br />
<br />
SOLE. 2009. “Applications Divisons.” In The International Society of Logistics (SOLE). Hyattsville, MD, USA, accessed August 5, 2010. http://www.sole.org/appdiv.asp.<br />
<br />
Sukamto, S. 2003. “Plant Aging and Life Extension Program at Arun LNG Plant Lhokseumawe, North Aceh, Indonesia.” Paper presented at 22nd Annual World Gas Conference, June 1-5, Tokyo, Japan.<br />
<br />
----<br />
<center>[[Service Life Management|< Previous Article]] | [[System Maintenance|Parent Article]] | [[Capability Updates, Upgrades, and Modernization|Next Article >]]</center><br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center><br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Product and Service Life Management]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=Service_Life_Management&diff=65004
Service Life Management
2022-05-18T09:50:14Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div>----<br />
'''''Contributing Author:''''' ''William Stiffler''<br />
----<br />
Product and service life management deals with the overall life cycle planning and support of a system. The life of a product or service spans a considerably longer period of time than the time required to design and develop the system. Systems engineers need to understand and apply the principles of life management throughout the {{Term|Life Cycle (glossary)|life cycle}} of the system. (See [[Life Cycle Models]] for a general discussion of life cycles.) Specifically, this knowledge area (KA) focuses on changes to a system after deployment, including extension, modernization, disposal, and retirement.<br />
<br />
==Topics==<br />
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics: <br />
*[[Service Life Extension]]<br />
*[[Capability Updates, Upgrades, and Modernization]]<br />
*[[Disposal and Retirement]]<br />
See the article [[Matrix of Implementation Examples]] for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3.<br />
<br />
==Overview==<br />
Product and service life management is also referred to as ''system sustainment''. Sustainment involves the supportability of operational systems from the initial procurement to disposal. Sustainment is a key task for systems engineering that influences product and service performance and support costs for the entire life of the program. <br />
<br />
Sustainment activities include: design for maintainability, application of built-in test, diagnostics, prognostics and other condition-based maintenance techniques, implementation of logistics footprint reduction strategies, identification of technology insertion opportunities, identification of operations and support cost reduction opportunities, and monitoring of key support metrics. Life cycle sustainment plans should be created for large, complex systems (DAU 2010). Product and service life management applies to both commercial systems (e.g. energy generation and distribution systems, information management systems, the Internet, and health industries) and government systems (e.g. defense systems, transportation systems, water-handling systems, and government services).<br />
<br />
It is critical that the planning for system life management occur during the requirements phase of system development. (See [[System Requirements]] and [[System Definition]]). The requirements phase includes the analysis of life cycle cost alternatives, as well as gaining the understanding of how the system will be sustained and modified once it is operational. <br />
<br />
The body of knowledge associated with product and service life management includes the following areas:<br />
#[[Service Life Extension]] - Systems engineers need to understand the principles of service life extension, the challenges that occur during system modifications, and issues involved with the disposal and retirement after a system has reached the end of its {{Term|Useful life (glossary)|useful life}}. <br />
#[[Capability Updates, Upgrades, and Modernization|Modernization and Upgrades]] - Managing service life extension uses the {{Term|Engineering Change Management (glossary)|engineering change management}} process with an understanding of the design life constraints of the system. Modernizing existing {{Term|Legacy System (glossary)|legacy systems}} requires special attention and understanding of the legacy requirements and the importance of having a complete inventory of all the system interfaces and technical drawings. <br />
#[[Disposal and Retirement]] - Disposal and retirement of a product after reaching its useful life requires attention to environmental concerns, special handling of hazardous waste, and concurrent operation of a replacement system as the existing system is being retired.<br />
<br />
==Principles and Standards==<br />
The principles of product and service life management apply to different types of systems and domains. The type of system (commercial or government) should be used to select the correct body of knowledge and best practices that exist in different domains. For example, U.S. military systems would rely on sustainment references and best practices from the Department of Defense (DoD) (e.g., military services, Defense Acquisition University (DAU), etc.) and military standardization bodies (e.g., the American Institute of Aeronautics and Astronautics (AIAA), the Society of Automotive Engineers (SAE), the Society of Logistics Engineers (SOLE), the Open Geospatial Consortium (OGC), etc.).<br />
<br />
Commercial aviation, power distribution, transportation, water-handling systems, the Internet, and health industries would rely on system life management references and best practices from a combination of government agencies, local municipalities, and commercial standardization bodies and associations (e.g., in the U.S.- the Department of Transportation (DOT), State of Michigan, International Organization for Standardization (ISO), Institute of Electrical and Electronics Engineers (IEEE), International Council on Systems Engineering (INCOSE), etc.). <br />
<br />
Some standardization bodies have developed system life management practices that bridge both military and commercial systems (e.g., INCOSE, SOLE, ISO, IEEE, etc.). There are multiple commercial associations involved with defining engineering policies, best practices, and requirements for commercial product and service life management. Each commercial association has a specific focus for the market or domain area where the product is used. Examples of such commercial associations in the U.S. include: American Society of Hospital Engineering (ASHE); Association of Computing Machinery (ACM); American Society of Mechanical Engineers (ASME); American Society for Testing & Materials (ASTM) International; National Association of Home Builders (NAHB); and Internet Society (ISOC), including Internet Engineering Task Force (IETF), and SAE.<br />
<br />
In addition, there are several specific resources which provide useful information on product and service life management:<br />
*The ''[[INCOSE Systems Engineering Handbook]]'', version 3.2.2, identifies several relevant points regarding product and service life management (2011).<br />
*The ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]]'', version 1.1, provides guidance on product changes and system retirement (Caltrans and USDOT 2005). <br />
*''[[Systems Engineering and Analysis]]'' emphasizes design for supportability and provides a framework for product and service supportability and planning for system retirement (Blanchard and Fabrycky 2006).<br />
*''[[Modernizing Legacy Systems]]'' identifies strategies for product and service modernization (Seacord, Plakosh, and Lewis 2003).<br />
*"[[Logistics and Materiel Readiness]]" ([http://www.acq.osd.mil/log/ http://www.acq.osd.mil/log/]) provides online policies, procedures, and planning references for product service life extension, modernization, and retirement (OUSD(AT&L) 2011).<br />
*''[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]]'' provides insight into architecting a system for extended service life (Jackson 2007).<br />
<br />
==Good Practices== <br />
Major pitfalls associated with systems engineering (SE) after the deployment of products and services can be avoided if the systems engineer:<br />
*Recognizes that the systems engineering process does not stop when the product or service becomes operational.<br />
*Understands that certain life management functions and organizations, especially in the post-delivery phase of the life cycle, are part of the systems engineering process.<br />
* Identifies that modifications need to comply with the system requirements. <br />
*Considers that the users must be able to continue the maintenance activities drawn up during the system requirement phase after an upgrade or modification to the system is made.<br />
*Accounts for changing user requirements over the system life cycle.<br />
*Adapts the support concepts drawn up during development throughout the system life cycle.<br />
*Applies engineering change management to the total system.<br />
<br />
Not addressing these areas of concern early in development and throughout the product or service’s life cycle can have dire consequences.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Blanchard, B.S. and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]],'' 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' version 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research & Innovation/U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
DAU. 2010. “Acquisition Community Connection (ACC): Where the DoD AT&L workforce meets to share knowledge.” Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/US Department of Defense (DoD). https://acc.dau.mil.<br />
<br />
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.<br />
<br />
Jackson. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science.'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Aquisition, Transportation and Logistics (OUSD(AT&L)). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R.C., D. Plakosh, and G.A. Lewis. 2003. ''[[Modernizing Legacy Systems]]: Software Technologies, Engineering Processes, and Business Practices''. Boston, MA, USA: Pearson Education.<br />
<br />
===Primary References===<br />
<br />
Blanchard, B.S. and W.J. Fabrycky. 2011. ''[[Systems Engineering and Analysis]],'' 5th ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Caltrans and USDOT. 2005. ''[[Systems Engineering Guidebook for Intelligent Transportation Systems (ITS)]],'' ver 1.1. Sacramento, CA, USA: California Department of Transportation (Caltrans) Division of Research and Innovation and U.S. Department of Transportation (USDOT), SEG for ITS 1.1.<br />
<br />
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook|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.<br />
<br />
Jackson, S. 2007. “[[A Multidisciplinary Framework for Resilience to Disasters and Disruptions]].” ''Journal of Integrated Design and Process Science.'' 11(2).<br />
<br />
OUSD(AT&L). 2011. “[[Logistics and Materiel Readiness]] On-line policies, procedures, and planning references.” Arlington, VA, USA: Office of the Under Secretary of Defense for Acquisition, Transportation and Logistics (OUSD(AT&L). http://www.acq.osd.mil/log/.<br />
<br />
Seacord, R.C., D. Plakosh, and G.A. Lewis. 2003. ''[[Modernizing Legacy Systems]]: Software Technologies, Engineering Processes, and Business Practices''. Boston, MA, USA: Pearson Education.<br />
<br />
===Additional References===<br />
<br />
Blanchard, B.S. 2010. ''Logistics engineering and management,'' 5th ed. Englewood Cliffs, NJ, USA: Prentice Hall: 341-342.<br />
<br />
Braunstein, A. 2007. “Balancing Hardware End-of-Life Costs and Responsibilities.” Westport, CT, USA: Experture Group, ETS 07-12-18. <br />
<br />
Brown, M., R. Weyers, and M. Sprinkel. 2006. “Service Life Extension of Virginia Bridge Decks afforded by Epoxy-Coated Reinforcement.” ''Journal of ASTM International (JAI).'' 3(2): 13. <br />
<br />
DLA. 2010. “Defense logistics agency disposition services.” In Defense Logistics Agency (DLA)/U.S. Department of Defense [database online]. Battle Creek, MI, USA, accessed June 19 2010: 5. Available at: http://www.dtc.dla.mil.<br />
<br />
EPA. 2010. “Wastes In U.S. Environmental Protection Agency (EPA)." Washington, D.C. Available at: http://www.epa.gov/epawaste/index.htm.<br />
<br />
Finlayson, B. and B. Herdlick. 2008. ''Systems Engineering of Deployed Systems.'' Baltimore, MD, USA: Johns Hopkins University: 28. <br />
<br />
FSA. 2010. “Template for 'System Retirement Plan' and 'System Disposal Plan'.” In Federal Student Aid (FSA)/U.S. Department of Eduation (DoEd). Washington, DC, USA. Accessed August 5, 2010. Available at: http://federalstudentaid.ed.gov/business/lcm.html.<br />
<br />
Gehring, G., D. Lindemuth, and W.T. Young. 2004. “Break Reduction/Life extension Program for CAST and Ductile Iron Water Mains.” Paper presented at NO-DIG 2004, Conference of the North American Society for Trenchless Technology (NASTT), March 22-24, New Orleans, LA, USA. <br />
<br />
Hovinga, M.N., and G.J. Nakoneczny. 2000. “Standard Recommendations for Pressure Part Inspection during a Boiler Life Extension Program.” Paper presented at ICOLM (International Conference on Life Management and Life Extension of Power Plant), May, Xi’an, P.R. China. <br />
<br />
IEC. 2007. ''Obsolescence Management - Application Guide'', ed 1.0. Geneva, Switzerland: International Electrotechnical Commission, IEC 62302. <br />
<br />
ISO/IEC/IEEE. 2015.[[ISO/IEC/IEEE 15288| ''Systems and Software Engineering -- System Life Cycle Processes'']]. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.<br />
<br />
Ihii, K., C.F. Eubanks, and P. Di Marco. 1994. “Design for Product Retirement and Material Life-Cycle.” ''Materials & Design.'' 15(4): 225-33. <br />
<br />
INCOSE UK Chapter. 2010. ''Applying Systems Engineering to In-Service Systems: Supplementary Guidance to the INCOSE Systems Engineering Handbook,'' version 3.2, issue 1.0. Foresgate, UK: International Council on Systems Engineering (INCOSE) UK Chapter: 10, 13, 23. <br />
<br />
Institute of Engineers Singapore. 2009. ''Systems Engineering Body of Knowledge, provisional,'' version 2.0. Singapore. <br />
<br />
Jackson, S. 1997. ''Systems Engineering for Commercial Aircraft.'' Surrey, UK: Ashgate Publishing, Ltd. <br />
<br />
Koopman, P. 1999. “Life Cycle Considerations.” Pittsburgh, PA, USA: Carnegie Mellon. Accessed August 5, 2010. Available at: http://www.ece.cmu.edu/~koopman/des_s99/life_cycle/index.html.<br />
<br />
L3 Communications. 2010. “Service Life Extension Program (SLEP).” Newport News, VA, USA: L3 Communications, Flight International Aviation LLC. <br />
<br />
Livingston, H. 2010. “GEB1: Diminishing Manufacturing Sources and Material Shortages (DMSMS) Management Practices.” McClellan, CA, USA: Defense MicroElectronics Activity (DMEA)/U.S. Department of Defense (DoD). <br />
<br />
Minneapolis-St. Paul Chapter of SOLE. 2003. "Systems Engineering in Systems Deployment and Retirement, presented to INCOSE." Minneapolis-St. Paul, MN, USA: International Society of Logistics (SOLE), Minneapolis-St. Paul Chapter. <br />
<br />
NAS. 2006. ''National Airspace System (NAS) System Engineering Manual,'' version 3.1 (volumes 1-3). Washington, D.C.: Air Traffic Organization (ATO)/U.S. Federal Aviation Administration (FAA), NAS SEM 3.1. <br />
<br />
NASA. 2007. ''Systems Engineering Handbook.'' Washington, DC, USA: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105, December 2007.<br />
<br />
Nguyen, L. 2006. “Adapting the Vee Model to Accomplish Systems Engineering on Change Projects.” Paper presented at 9th Annual National Defense Industrial Association (NDIA) Systems Engineering Conference, San Diego, CA, USA. <br />
<br />
Office of Natural Gas and Oil Technology. 1999. ''Reservoir LIFE Extension Program: Encouraging Production of Remaining Oil and Gas.'' Washington, DC, USA: U.S. Department of Energy (DoE). <br />
<br />
Paks Nuclear Power Plant. 2010. “Paks Nuclear Power Plant: Service Life Extension.” In Paks Nuclear Power Plant, Ltd.. Hungary, accessed August 5, 2010. Available at: http://paksnuclearpowerplant.com/service-life-extension.<br />
<br />
Ryen, E. 2008. ''Overview of the Systems Engineering Process.'' Bismarck, ND, USA: North Dakota Department of Transportation (NDDOT). <br />
<br />
SAE International. 2010. “Standards: Commercial Vehicle--Maintenance and Aftermarket.” Warrendale, PA, USA: Society of Automotive Engineers (SAE) International. <br />
<br />
SAE International. 2010. “Standards: Maintenance and Aftermarket.” Warrendale, PA, USA: Society of Automotive Engineers (SAE) International. <br />
<br />
Sukamto, S. 2003. “Plant Aging and Life Extension Program at Arun LNG Plant Lhokseumawe, North Aceh, Indonesia.” Paper presented at 22nd Annual World Gas Conference, June 1-5, Tokyo, Japan.<br />
<br />
----<br />
<center>[[Logistics|< Previous Article]] | [[System Maintenance|Parent Article]] | [[Service Life Extension|Next Article >]]</center><br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center><br />
<br />
[[Category: Part 3]][[Category:Knowledge Area]]</div>
Mhaas
https://sebokwiki.org/w/index.php?title=Logistics&diff=65003
Logistics
2022-05-18T09:49:33Z
<p>Mhaas: Updated Navigation</p>
<hr />
<div>----<br />
'''''Lead Authors:''''' ''Scott Jackson, John Snoderly'', '''''Contributing Author:''''' ''Garry Roedler''<br />
----<br />
There are several definitions for {{Term|logistics (glossary)|logistics}} within {{Term|Systems Engineering (glossary)|systems engineering}} (SE) and the definition used will determine what activities are considered part of logistics. The SEBoK defines logistics as the science of planning and implementing the acquisition and use of the resources necessary to sustain the operation of a system.<br />
<br />
==Overview==<br />
The ability to ''sustain the operation of a system'' is determined by the inherent supportability of the system (a function of design) and the processes used to sustain the functions and capabilities of the system in the context of the end user. Figure 1, below, shows a Defense Acquisition University (DAU) model of the SE aspects for consideration in logistics and logistics planning (DAU 2010).<br />
<br />
[[File:Affordable_Sys_Ops_Effect_DAU_GB_Roedler.jpg|thumb|600px|center|'''Figure 1. Affordable System Operational Effectiveness (DAU Guidebook 2010).''' Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).]]<br />
<br />
==Sustainment Planning==<br />
The focus of {{Term|sustainment (glossary)|sustainment}} planning is to influence the inherent supportability of the system and to plan the sustainment capabilities and processes that will be used to sustain system operations.<br />
<br />
===Influence Inherent Supportability (Operational Suitability)===<br />
Sustainment influence requires an understanding of the {{Term|Concept of Operations (ConOps) (glossary)|concept of operations}} (ConOps), system {{Term|Mission (glossary)|missions}}, mission profiles, and {{Term|System Capability (glossary)|system capabilities}} to understand the rationale behind functional and performance priorities. Understanding the rationale paves the way for decisions about necessary tradeoffs between system performance, {{Term|Availability (glossary)|availability}}, and {{Term|Life Cycle Cost (LCC) (glossary)|life cycle cost}} (LCC), with impact on the cost effectiveness of [[Operation of the System|system operation]], [[System Maintenance|maintenance]], and logistics support. There is no single list of sustainment considerations or specific way of grouping them as they are highly inter-related. They include: compatibility, {{Term|interoperability (glossary)|interoperability}}, transportability, {{Term|reliability (glossary)|reliability}}, {{Term|maintainability (glossary)|maintainability}}, {{Term|manpower (glossary)|manpower}}, {{Term|Human Factors (glossary)|human factors}}, {{Term|safety (glossary)|safety}}, natural environment effects (including occupational health, habitability; see [[Environmental Engineering]]); diagnostics & prognostics (including real-time maintenance data collection), and corrosion protection & mitigation. The following are key design considerations:<br />
<br />
* '''{{Term|Architecture (glossary)|Architecture Considerations}}''' - The focus on openness, modularity, scalability, and upgradeability is critical to implementing an incremental acquisition strategy. In addition, the architecture attributes that expand system {{Term|flexibility (glossary)|flexibility}} and affordability can pay dividends later when obsolescence and end-of-life issues are resolved through a concerted technology refreshment strategy. Trade-offs are often required relative to the extent each attribute is used.<br />
* '''{{Term|Reliability (glossary)|Reliability Considerations}}''': - Reliability is critical because it contributes to a system's effectiveness as well as its suitability in terms of logistics burden and the cost to fix {{Term|Failure (glossary)|failures}}. For each system, there is a level of basic reliability that must be achieved for the system to be considered useful. Reliability is also one of the most critical elements in determining the logistics infrastructure and footprint. Consequently, system reliability should be a primary focus during design (along with system technical performance, functions, and capabilities). The primary objective is to achieve the necessary probability of operational success and minimize the risk of failure within defined availability, cost, schedule, weight, power, and volume constraints. While performing such analyses, trade-offs should be conducted and dependencies should be explored with system maintainability and integrated with the supportability analysis that addresses support event frequency (i.e. reliability), event duration, and event cost. Such a focus will play a significant role in minimizing the necessary logistics footprint, while maximizing system availability.<br />
* '''{{Term|Maintainability (glossary)|Maintainability Considerations}}''' - The design emphasis on maintainability is to reduce the maintenance burden and supply chain by reducing the time, personnel, tools, test equipment, training, facilities and cost to maintain the system. Maintainability engineering includes the activities, methods, and practices used to design minimal system maintenance requirements (designing out unnecessary and inefficient processes) and associated costs for preventive and corrective maintenance as well as servicing or calibration activities. Maintainability should be a designed-in capability and not an add-on option because good maintenance procedures cannot overcome poor system and equipment maintainability design. The primary objective is to reduce the time it takes for a properly trained maintainer to detect and isolate the failure (coverage and efficiency) and affect repair. Intrinsic factors contributing to maintainability are:<br />
** '''{{Term|Modularity (glossary)|Modularity}}''' - Packaging of components such that they can be repaired via remove and replace action vs. on-board repair. Care should be taken not to ''over modularize,'' and trade-offs to evaluate replacement, transportation, and repair costs should be accomplished to determine the most cost-effective approach.<br />
** '''Interoperability''' - The compatibility of components with standard interface protocols to facilitate rapid repair and enhancement/upgrade through black box technology using common interfaces. Physical interfaces should be designed so that mating between components can only happen correctly.<br />
** '''Physical accessibility''' - The designed-in structural assurance that components which require more frequent monitoring, checkout, and maintenance can be easily accessed. This is especially important in low observable platforms. Maintenance points should be directly visible and accessible to maintainers, including access for corrosion inspection and mitigation.<br />
** Designs that require ''minimum preventative maintenance'' including corrosion prevention and mitigation. Emphasis should be on balancing the maintenance requirement over the life cycle with minimal user workload.<br />
** '''Embedded training and testing''' when it is determined to be the optimal solution from a {{Term|Total Ownership Cost (glossary)|total ownership cost}} (TOC) and materiel availability perspective.<br />
** '''{{Term|Human Systems Integration (HSI) (glossary)|Human Systems Integration}} (HSI)''' to optimize total system performance and minimize life-cycle costs by designing systems and incorporating technologies that (a) require minimal manpower, (b) provide effective training, (c) can be operated and maintained by users, (d) are suitable (habitable and safe with minimal environmental and occupational health hazards), and (e) are survivable (for both the user and the equipment).<br />
* '''Support Considerations''' - Support features cannot be easily ''added-on'' after the design is established. Consequently, supportability should be a high priority early in the program's planning and integral to the system design and development process. Support features cut across reliability, maintainability, and the supply chain to facilitate detection, isolation, and timely repair/replacement of system anomalies. These include features for servicing and other activities necessary for operation and support including resources that contribute to the overall support of the system. Typical supportability features include diagnostics, prognostics (see CBM+ Guidebook), calibration requirements, many HSI issues (e.g. training, safety, HFE, occupational health, etc.), skill levels, documentation, maintenance data collection, compatibility, interoperability, transportability, handling (e.g., lift/hard/tie down points, etc.), packing requirements, facility requirements, accessibility, and other factors that contribute to an optimum environment for sustaining an operational system.<br />
<br />
==Planning Sustainment Processes==<br />
Process efficiency reflects how well the system can be produced, operated, serviced (including fueling) and maintained. It reflects the degree to which the logistics processes (including the supply chain), infrastructure, and footprint have been balanced to provide an agile, deployable, and operationally effective system. <br />
<br />
Achieving process efficiency requires early and continuing emphasis on the various logistics support processes along with the design considerations. The continued emphasis is important because processes present opportunities for improving operational effectiveness even after the ''design-in'' window has passed via lean-six sigma, supply chain optimization, or other continuous process improvement (CPI) techniques.<br />
<br />
==Sustainment Analysis (Product Support Package)==<br />
<br />
The product support package documents the output of supportability analysis and includes details related to the following twelve elements (links below are to excerpts from (NATO RTO 2001):<br />
<br />
* Product/information technology (IT) system/medical system support management (integrated life cycle sustainment planning)<br />
** product/IT system/medical system support strategies<br />
** life cycle sustainment planning<br />
** requirements management<br />
** {{Term|Total Ownership Cost (glossary)|total ownership costs}} (TOC)/{{Term|Life Cycle Cost (LCC) (glossary)|life cycle costs}} (LCC) planning & management<br />
** {{Term|Integration (glossary)|Integration}} and management of product support activities<br />
** {{Term|Configuration Management (glossary)|configuration management}}<br />
** production & distribution<br />
** energy, environmental, safety and health (EESH) management<br />
** policies & guidance<br />
** {{Term|Risk Management (glossary)|risk management}}<br />
* [http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-12.pdf Design Interface]<br />
** {{Term|Reliability (glossary)|reliability}}<br />
** {{Term|Maintainability (glossary)|maintainability}}<br />
** supportability<br />
** affordability<br />
** {{Term|Configuration Management (glossary)|configuration management}}<br />
** safety requirements<br />
** environmental and hazardous materials (HAZMAT) requirements<br />
** {{Term|Human Systems Integration (HSI) (glossary)|human systems integration}} (HSI)<br />
** calibration<br />
** anti-tamper<br />
** habitability<br />
** disposal<br />
** legal requirements<br />
* Sustainment Engineering<br />
** failure reporting, analysis, and corrective action system (FRACAS)<br />
** value engineering<br />
** diminishing manufacturing sources and material shortages (DMSMS)<br />
* [http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-06.pdf Supply Support (materiel planning)]<br />
* [http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-03.pdf Maintenance Planning]<br />
** reliability centered maintenance (RCM)<br />
** maintenance concepts<br />
** levels of maintenance (level of repair analysis)<br />
** condition-based maintenance<br />
** prognostics & health management<br />
* [http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-05.pdf Support Equipment]<br />
* [http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-07.pdf Technical Data]<br />
* [http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-04.pdf Manpower & Personnel]<br />
* [http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-08.pdf Training & Training Support]<br />
* [http://www.decisionlens.com/docs/WP_Strategic_Facilities_and_Infrastructure_Planning.pdf Facilities & Infrastructure]<br />
* [http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-11.pdf Packaging, Handling, Storage, & Transportation]<br />
* [http://ftp.rta.nato.int/public/PubFullText/RTO/AG/RTO-AG-300-V20/AG-300-V20-09.pdf Computer Resources]<br />
<br />
==Sustainment Implementation==<br />
Once the system becomes operational, the results of sustainment planning efforts need to be implemented. SE supports the execution of the twelve integrated product support elements of a sustainment program that strives to ensure the system meets operational performance requirements in the most cost-effective manner over its total remaining life cycle, as illustrated in Figure 2.<br />
<br />
[[File:Sustainment_Implementation_Illustration_Logistics_Roedler.jpg|thumb|center|600px|'''Figure 2. Sustainment Implementation Illustration (DAU Guidebook 2012).''' Released by Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).]]<br />
<br />
Once a system is put into use, SE is often required to correct problems that degrade continued use, and/or to add new capabilities to improve product performance in the current or a new environment. In the context of integrated product support, these SE activities correspond to the integrated product support (IPS) element ''Sustaining Engineering.'' Changes made to fielded systems to correct problems or increase performance should include any necessary adjustments to the IPS elements, and should consider the interrelationships and integration of the elements to maintain the effectiveness of the system’s support strategy.<br />
<br />
The degree of change required to the product support elements varies with the severity of the problem. Minor problems may require a simple adjustment to a maintenance procedure, a change of supplier, a training course modification or a change to a technical manual. In contrast, problems that require system or component redesign may require engineering change proposals and approvals, IPS element trade studies, business case analysis, and updates to the product support strategy. The focus is to correct problems that degrade continued use, regardless of the degree of severity.<br />
<br />
Evolutionary systems provide a strategy for acquisition of mature technology; the system delivers capabilities incrementally, planning for future capability enhancements. A {{Term|System of Systems (SoS) (glossary)|system of systems}} (SoS) perspective is required for these systems to synchronize the primary and sustainment systems.<br />
<br />
For more information refer to: ''An Enterprise Framework for Operationally Effective System of Systems Design'' (Bobinis and Herald 2012.).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Bobinis, J. and T. Herald. 2012. “[[An Enterprise Framework for Operationally Effective System of Systems Design|An enterprise framework for operationally effective system of systems design]].” ''Journal of Enterprise Architecture.'' Vol. 8, no. 2, May 2012. Available at: https:// www.mendling.com/publications/JEA12-2.pdf.<br />
<br />
DAU. 2010. [[Defense Acquisition Guidebook (DAG)]]. Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).<br />
<br />
NATO RTO. 2001. ''Logistics Test and Evaluation in Flight Test''. Flight Test Techniques Series – Volume 20. Quebec, Canada: North Atlantic Treaty Organization (NATO) Research and Technology Organization (RTO). RTO-AG-300 Vol. 20, AC/323(SCI-010)TP/38. Table of contents available at: http://ftp.rta.nato.int/public//PubFullText/RTO/AG/RTO-AG-300-V20///AG-300-V20-$$TOC.pdf<br />
<br />
===Primary References===<br />
Blanchard, B.S. 1998. ''[[Logistics Engineering and Management]].'' Upper Saddle River, NJ, USA: Prentice Hall.<br />
<br />
Blanchard, B. and W. Fabrycky. 2011. ''[[Systems Engineering and Analysis]],'' 5th Ed. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Bobinis, J. and T. Herald. 2012. “[[An Enterprise Framework for Operationally Effective System of Systems Design|An enterprise framework for operationally effective system of systems design]].” ''Journal of Enterprise Architecture.'' Vol. 8, no. 2, May 2012. Available at: https:// www.mendling.com/publications/JEA12-2.pdf.<br />
<br />
Daganzo, C. 2005. ''[[Logistics Systems Analysis]],'' 4th Edition. New York, NY, USA: Springer.<br />
<br />
Fabrycky, W.J. and B.S. Blanchard. 1991. ''[[Life-Cycle Cost and Economic Analysis]]''. Upper Saddle River, NJ, USA: Prentice-Hall.<br />
<br />
Ghiani, G., G. Laporte, and R. Musmanno. 2004. ''[[Introduction to Logistics Systems Planning and Control]].'' Hoboken, NJ, USA: Wiley-Interscience.<br />
<br />
Jones, J.V. 1995. ''[[Integrated Logistics Support Handbook]].'' New York, NY, USA: McGraw Hill.<br />
<br />
===Additional References===<br />
Barros, L.L. 1998. "The optimization of repair decision using life-cycle cost parameters." ''IMA Journal of Management Mathematics.'' Vol. 9, no. 4, p. 403.<br />
<br />
Berkowitz, D., J.N. Gupta, J.T. Simpson, and J.B. McWilliams. 2005. ''Defining and Implementing Performance-Based Logistics in Government''. Washington, DC, USA: Defense Technical Information Center. Accessed 6 Sept 2011. Available at: http://handle.dtic.mil/100.2/ADP018510.<br />
<br />
Gajpal, P.P., L.S. Ganesh, and C. Rajendran. 1994. "Criticality analysis of spare parts using the analytic hierarchy process." ''International Journal of Production Economics.'' Vol. 35, nos. 1-3 pp. 293-297. <br />
<br />
MITRE. 2011. "Integrated logistics support." ''Systems Engineering Guide.'' Accessed 11 March 2012. Available at: [[http://www.mitre.org/work/systems_engineering/guide/acquisition_systems_engineering/integrated_logistics_support/]].<br />
<br />
Murthy, D.N.P. and W.R. Blischke. 2000. "Strategic warranty management: A life-cycle approach." ''Engineering Management.'' Vol. 47, no. 1, pp. 40-54.<br />
<br />
Northrop Grumman Corporation. 2000. ''Logistics Systems Engineering''. Accessed 6 Sept 2011. Available at: http://www.northropgrumman.com/Capabilities/NavigationSystemsLogisticsSystemsEngineering/Documents/nsd_logistics.pdf.<br />
<br />
Solomon, R., P.A. Sandborn, and M.G. Pecht. 2000. "Electronic part life cycle concepts and obsolescence forecasting." ''IEEE Transactions on Components and Packaging Technologies.'' Vol. 23, no. 4, pp. 707-717. <br />
<br />
Spengler, T. and M. Schroter. 2003. "Strategic management of spare parts in closed-loop supply chains: A system dynamics approach." ''Interfaces.'' pp. 7-17.<br />
<br />
----<br />
<center>[[System Maintenance|< Previous Article]] | [[System Maintenance|Parent Article]] | [[Service Life Management|Next Article >]]</center><br />
<br />
<center>'''SEBoK v. 2.6, released 13 May 2022'''</center><br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Deployment and Use]]</div>
Mhaas