Systems Engineering and Enterprise IT

From SEBoK
Jump to navigation Jump to search

Lead Authors: Chuck Walrad and Richard Hilliard

This article discusses Enterprise IT (EIT) building on the concepts and practices of Systems Engineering (SE) presented elsewhere in the SEBOK. SE is integral to the effective functioning of EIT organizations, whose work is devoted to the successful realization, use, and retirement of engineered technical systems.

Enterprise IT Introduction

Systems Engineering is integral to the effective functioning of EIT organizations, whose work is devoted to the successful realization, use, and retirement of Engineered Technical SystemsEngineered Technical Systems (create new glossary term pointing to this income reference) engineered technical systems. 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. 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 Standish (1994). The Standish Group research shows a staggering 31.1% of projects were canceled before they ever got completed. Further results indicated 52.7% of projects cost 189% of their original estimates. The cost of these failures and overruns were just the tip of the proverbial iceberg. The lost opportunity costs were not measurable but could easily be in the trillions of dollars.

As a result, commercial IT organizations through the auspicious parallel emergence of the Total Quality Management movement (ASQ n.d.) and the increasingly widespread development of application development methodologies by IT management consulting firms, recognized the need for the principles of SE and cross-functional teams (sometimes called Integrated Product Teams (IPTs)Integrated Product Teams (IPTs)). It should be noted that there is considerable overlap today between SE and Project Management (PM) (see Systems Engineering and Project Management). Note that the following business management activities can be supported by Enterprise Systems Engineering (ESE) activities:

  • mission and strategic planning
  • business processes and information management
  • performance management
  • portfolio management
  • resource allocation and budgeting
  • program and project management

These same areas are often supported by Project Management Offices. However, since a key difference between PM and SE is that the latter includes technical expertise in the product/system of concern, focus should be on SE and IPTs.

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.

As enterprises have come to depend more and more on technology to perform effectively, EIT organizations have matured, often due to the influence of IT consulting firms that make it their business to keep abreast of best practices.

EIT Concepts

Much of this section builds on concepts found in the EITBOK, the Guide to the Enterprise Information Technology Body of Knowledge (IEEE/ACM n.d.), and on general SE concepts elsewhere in the SEBoK.

An enterprise may be viewed from various perspectives: such as a system or system of systems (SoS):

  • system-like enterprise: enterprises, like other systems, may have a tight coupling, single-executive function;
  • system of systems-like enterprise: may be a loosely coupled group of organizations with blurred boundaries and (yet) with (some) shared outcomes.

The choice of perspective may vary with many factors: the enterprise itself, the mission or purpose, or the particular engineering task at hand. The enterprise can be viewed as a system with inputs and outputs in relation to the outside world, or as a system of systems interacting through its individual component inputs and outputs.

An enterprise usually involves one or more organizations 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 its customers.

Whatever perspective is taken (system-like, SoS-like, other), there are common key ingredients of any enterprise: capabilities, individual competencies, and the organizational design. Capabilities can be further categorized into organizational, system, and operational. These capabilities determine what the enterprise is able to produce, which may be external offerings or internal mechanisms. Operational capabilities create services and products which in turn produce value as determined by stakeholders. The capabilities of an enterprise are realized through various enterprise elements including hardware, software, personnel, facilities, data, materials, techniques, and even services which include soft items such as people, processes, principles, policies, practices, organizations, doctrine, theories, and beliefs.

EIT capabilities exist through lifecycles spanning from creation through eventual replacement and disposal. System Lifecycle Models aid in understanding, designing, planning and managing the capability of interest.

“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.” (IEEE/ACM n.d.) Basic life cycle terms and concepts are discussed in Systems Lifecycle Approaches. Some typical life cycles are discussed in System Lifecycle Models.

A life cycle-based approach can be deployed across the several levels and used to manage evolution. These levels are:

  • the enterprise itself
  • the processes and organizations constituting the enterprise
  • the systems enabling the capabilities, services or products provided.

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 or withdrawal. Each of these stages is usually managed as a project or a series of projects.

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).

System of Systems Context in EIT

The phrase “Enterprise IT” (EIT) is often used both to refer to the technology organization/business unit within the enterprise and to the enterprise’s information technology systems. This can be confusing. Here EIT refers to technology systems. When referring to the organization, “Enterprise IT organization” or EIT organization is used instead.

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:

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. SE should consider the full engineered system context so that the necessary understanding can be reached and the right systems engineering decisions can be made.

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. A complex of EIT systems is essential to the successful functioning of the people in the enterprise. They rely on EIT’s technology for communication, paying employees, people management, 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.” (IEEE/ACM n.d. (a))

To accomplish this mission, the EIT organization builds and acquires new systems or system components, integrates them into the mega SoS, and maintains the integrity and interoperability of the individual components as well as the integrity of the entire complex of systems. In addition, security and performance levels must be achieved, benchmarked, and maintained or improved.

Major concerns of the EIT Organization

IEEE/ACM (n.d.) provides a good deal of information about many major concerns, which will not be replicated here. Instead, 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:

  • Enterprise Architecture
  • Strategy and Governance
  • Change
  • Interoperability of Component Systems
  • Security of Systems and Data

Enterprise Architecture

The EITBoK defines Enterprise Archirecure(EA) as the practice of conducting enterprise analysis, design, planning, and implementation using a holistic approach for the successful development and execution of strategy. (IEEE/ACM (n.d.) (b)) There are, in fact, many alternative definitions common in the community (see . The SEBoK Glossary lists several of them including the one from the EITBoK. 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 systems architecture and also software architecture [1].

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.

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.

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).

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.

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.

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.

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.

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.

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 relationsinto distinct views. Typical relations include Causality, Dependency, Client-Server, and Input-Output.

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:

  • Modularity (separate and group capabilities into modules by commonalities);
  • Network (modules are linked together);
  • Encapsulation (separating architecture modules use from how they are implemented);
  • Layer Hierarchy (separation through gradual refinement);
  • Regularity (uniformity of interactions, of structure within layer, within network).
  • Similarity/Difference (recognizing the limits of Regularity)

A simple pattern for architecture has been defined (Hofmeister et al. 2007). Its elements are Analysis, Synthesis and Evaluation. See Figure 1 below.

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.

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.

Architecture Evaluation validates whether chosen solutions satisfy ASRs or whether rework is needed (ISO/IEC/IEEE 42030 2019).

Applying the principles discussed above is pervasive in enacting the Analysis–Synthesis–Evaluation pattern iteratively.

Figure 1. A pattern for Architecture.

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. 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.

Error creating thumbnail: File missing
Figure 2. Relating Enterprise IT, Systems and Software Architecture.

See IEEE/ACM (n.d. (b)) for additional information.

Strategy and Governance

See the EITBOK’s section on Strategy and Governance for additional information.

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.. -EITBOK wiki

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. 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.

Change

See the EITBOK’s section on Change Initiatives for more information.

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. 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 change management. 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).

These latter types of change management are discussed in detail in the EITBOK’s section on Operations and Support.

Interoperability of Component Systems

See the EITBOK’s section on interoperability for more information.

As explained in the 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.

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.

Security of Systems and Data

There are only two types of companies: those that have been hacked, and those that will be. -FBI Director Robert Mueller, October 2012

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 -FBI Director James Comey, October 2014

See the EITBOK’s section on security for additional information.

While there are many definitions for security, most include the three dimensions of confidentiality, integrity, and availability (sometimes referred to as the CIA triad). As such, the primary goal of EIT security is to preserve the confidentiality, integrity, and availability of information and information systems.

The principles behind an organization’s 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:

  • Always understand the current risk tolerance of the enterprise with respect to information and device security.
  • Understand the security threats and potential damages to information, devices, and individuals.
  • Create and follow policies and procedures that keep cyberattack risk and damages at or below a tolerable level.
  • Effectively and efficiently detect and deal with

cyberattack incidents.

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 mobile security incidents very easily can outweigh the cost of the mobile device itself.

Quality of Systems and Services

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 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.

The EITBoK details the quality concepts of:

Disaster Preparedness

As explained in the EITBOK, disaster preparedness and 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 acceptable timeframe after an event. 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.

It provides the following examples of disasters and service interruptions that could occur and should be considered in prevention and recovery planning: These are examples of disasters:

  • Natural disaster affecting datacenters or EIT service operations (flood, fire, earthquake, wind)
  • Security breach resulting in a disaster (destruction of data, admin password changes, virus/malware installation, sabotage)
  • Usage error (accidental deletion, unplug/turn off system resulting in corruption)
  • Utility failure affecting datacenters (loss of power even after UPS)
  • Vendor failure (cloud provider security failure, oil spill)
  • Staffing issue (employment dispute/walkout, epidemic)

These are examples of unpreparedness:

  • Requiring use of computers or printers when power is out
  • Requiring use of Internet when power or connectivity is out
  • Single point of knowledge/control for administration access
  • Lack of offsite backup storage
  • Lack of working restoration from backups
  • Lack of failover datacenters in separate locations
  • Undocumented or out-of-date documentation for system interfaces
  • Requiring use of phones that are out of power
  • Lack of designation of leaders in restoration efforts (who is in charge of restoring service and they know they are in charge)
  • In general, no cohesive, comprehensive EIT service restoration plan

Operations and Support of Delivered Systems and Services

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.

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 Operations and Support Knowledge Area within the EITBOK.

ISO/IEC/IEEE 20000 may be used by any organization to develop and manage EIT operations, along with the current version of ITIL.

ITIL for many is the tool of choice for the operations and infrastructure side of IT, particularly for IT services.

Ethics

See the EITBOK’s section on ethics for additional information.

Both the IEEE and ACM require their members to adhere to Codes of Ethics. See the IEEE Code of Ethics and 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 Software Engineering Code of Ethics (also available here).

The organization should create an easily accessible Code of Ethics:

  • 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.
  • Vendors should be held to similar ethical standards.
  • Lists of employees who have signed off on the Code of Ethics are maintained by EIT governance.

The EITBOK has identified EIT ethical topics that include:

  • Those actions and decisions that may be illegal
  • Consideration of the social impact of the work at hand—if it will cause harm
  • Alignment of business and EIT strategies and policies to an ethical standard
  • Incorporation of the ideals of professionalism
  • Adherence to applicable regulatory intent
  • Protection for whistle blowers

Areas to specifically highlight:

  • Activities that interfere with or corrupt the proper function of computers, applications and systems
  • Activities that interfere with digital privacy or intellectual rights of others
  • Respect for confidentiality, privacy, permissions, and access rights
  • Inappropriate bias (skewing) of analysis and reporting
  • Inaction in the face of likely ethics violations

EIT Roles

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.

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. 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:

  • Business Sponsor/Champion
  • Enterprise Architect
  • Systems Engineer
  • Financial Manager
  • Application Architect
  • Business Analyst and/or Process Analyst
  • Data Analyst and/or Data Architect
  • Software Engineer and/or Programmer
  • Quality Assurance & Testing
  • Network Engineer
  • Telecoms Engineer
  • Integration Expert
  • Transition to Operations Manager
  • Release Manager
  • Availability Manager
  • Capacity Manager
  • Change Manager
  • Configuration Manager
  • EIT Operations Manager
  • Incident Management
  • Problem Manager
  • Service Level Manager
  • Database Administrator
  • Network Manager
  • Product Manager

System engineering activities orchestrate the work of these roles so that they function together, rather than in silos or at cross purposes.

Examples of Systems Engineering in EIT

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.

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.

  • 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.
  • 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.
  • 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.

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.

Key External Models of EIT Organizational Capability and Maturity

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.

IT-CMF: IT-Capability Maturity Framework

The IT-CMF had its origin in a quality improvement effort at Intel Labs Europe in Ireland. Its intent, as described at the 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 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”.

CMMI: Capability Maturity Model Integration (US)

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 Development, Services, Supplier Management, People Management, and Data Management.

SFIA: Skills Framework for the information Age (Europe, Canada and US)

The SFIA Framework has been downloaded and used by organizations and individuals in nearly 180 countries. It can be downloaded for free at [2]. 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.

E-CF: European Competency Framework (EU)

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 online.

I Competency Dictionary: EIT skills as Defined by METI/ IPA (Japan)

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.

ITIL: Information Technology Infrastructure Library

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 “library” itself continues to evolve. This comprises five distinct areas:

It originally grew out of a British government sponsored effort to regularize IT Service Management (ITSM).

References

Works Cited

ASQ. n.d. "What is Total Quality Management". American Society for Quality. Available at: https://asq.org/quality-resources/total-quality-management. Accessed on May 7, 2023.

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. Available at: https://csrc.nist.rip/library/NIST%20SP%20500-167.pdf

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

Hilliard, R. 2015. “Lessons from the fundamental unity of architecting”. Software Engineering in the Systems Context, editors: Ivar Jacobson and Harold 'Bud' Lawson.

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).

IEEE/ACM n.d. Guide to the Enterprise IT Body of Knowledge. IEEE and ACM. Available at: http://eitbokwiki.org. Accessed on May 7, 2023.

IEEE/ACM n.d. (a). Guide to the Enterprise IT Body of Knowledge. Article "What is the Enterprise Perspective". Available at:http://eitbokwiki.org/What_is_the_Enterprise_Perspective%3F Accessed on May 7, 2023.

IEEE/ACM n.d. (b). Guide to the Enterprise IT Body of Knowledge. Article "Enterprise Architecture". Available at: http://eitbokwiki.org/Enterprise_Architecture. Accessed on May 7, 2023.

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.

ISO/IEC/IEEE 42010 Users Group. Survey of Architecture Frameworks Available as: http://www.iso-architecture.org/42010/afs/

ISO/IEC/IEEE. 2011. ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description.

PMI. 2013. Software Extension to PMBOK® Guide – Fifth Edition. Newtown Square, PA, USA: Project Management Institute (PMI). Available at: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/software-extension-5th-edition. Accessed on May 7, 2023.

Rivera, R. 2013. “The PRISM Architecture Framework – Was it the Very First Enterprise Architecture Framework?” Journal of Enterprise Architecture, November 2013.

Standish Group. 1994. The Chaos Report. Available at: https://www.standishgroup.com/sample_research_files/chaos_report_1994.pdf Accessed May 7, 2023.

Zachman, J. 1987. “A Framework for Information Systems Architecture”. IBM Systems Journal, pp454-470, 1987

Primary References

IEEE Computer Society. Enterprise IT Body of Knowledge. Available: http://eitbokwiki.org

-=Additional References==

IT Capability Maturity Framework (IT-CMF): The Body of Knowledge Guide. 2015. Editors. Martin Curley, Jim Kenneally, Marian Carcary. Van Haren Publishing.

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.

International Standards Guiding EIT

ANSI/AIAA. 2012. ANSI/AIAA Guide to the Preparation of Operational Concept Documents. ANSI/AIAA G-043A-2012e.

IEEE 2012 Std 828™-2012, IEEE Standard for Configuration Management in Systems and Software Engineering.

ISO 10004:2012, Quality management—Customer satisfaction—Guidelines for monitoring and measuring

ISO 10007:2003, Quality management systems—Guidelines for configuration management

ISO 18238:2015, Space systems—Closed loop problem solving management

ISO/IEC 25010:2011 Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality models

ISO/IEC 16350:2015, Information technology—Systems and software engineering—Application management

ISO/IEC 19770-1:2012, Information technology—Software asset management—Part 1: Processes and tiered assessment of conformance

ISO/IEC 20000-1:2011, (IEEE Std 20000-1:2013) Information technology—Service management—Part 1: Service management system requirements

ISO/IEC 20000–2:2012, Information technology—Service management—Part 2: Guidance on the application of service management systems

ISO/IEC TR 20000–10:2015, Information technology—Service management—Part 10: Concepts and terminology

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®

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®

ISO/IEC/IEEE 14764-2006, Software Engineering—Software Lifecycle Processes—Maintenance

ISO/IEC 15939:2007, Systems and software engineering—Measurement process

ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.7, released 31 October 2022
Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Systems_Engineering_and_Enterprise_IT&oldid=66975"