[This post is also available in French]
This article aims to give an introduction to the issues involved in, and approaches to, deploying systems engineering within an organisation.
This article aims to give an introduction to the issues involved in, and approaches to, deploying systems engineering within an organisation.
There are several important aspects to consider when deploying systems engineering (training, techniques/models/calculation methods/simulation, information systems, knowledge management, processes, etc.).
This article is the first in a series, and will focus mainly on introducing aspects related to the underlying information systems (tools). This choice of starting subject is based primarily on pragmatic considerations.
For some years now the trend has been for organisations to work to transform their business and their offer in order to differentiate themselves from their competitors; at the same time, they are working increasingly in partnership with other organisations (increased reliance on subcontractors, multi-disciplinary consortia, etc.). This transformation often comes about almost by stealth, through piecemeal, market-driven decision-making. This results in new and often incompatible tools and information systems being introduced project by project; it is essential to get control over this issue before processes, training, etc. can be addressed in a coherent manner.
So the idea of this initial article is to introduce the issues involved in deploying systems engineering, which is based on relatively theoretical considerations, but with a very practical purpose (how to manage the tools and information systems which need to be implemented).
Like all articles in the Crescendo Technologies blog, this article does not aim to “lay down the law” in any dogmatic way. It is intended as basis of an area for discussion and reflection, which will build up into a useful resource for anyone looking to deploy systems engineering within their organisation.
2. What is systems engineering?
For dealing with the issues involved in deploying systems engineering, it seems reasonable to set out a basic definition of what is understood by “System” and “Systems Engineering”.
The intention here is absolutely not to offer a course on systems engineering, not even an introduction, but simply a set of possible definitions in order to frame the meaning and provide a context which will help in understanding this article.
2.1. What is a system?
“A construct of the mind, a set of propositions, principles and conclusions forming a body of doctrine.”
“A coherent theoretical construct which takes account of a wide set of phenomena.”
These definitions underline the arbitrary aspect of a system, and the connection between that and the engineering (as in “construct”) associated with it.
According to the INCOSE, it is:
“An interacting combination of elements viewed in relation to function.”
This definition illustrates clearly that a system has no meaning without the context in which it is considered, and that its purpose justifies its existence.
For the sake of pragmatism and efficient communication, when talking of a system, one should generally state clearly what kind of system is being talked about in order to establish a comprehensible framework in which to study it. Examples:
- Articulated system: a mechanism made up of an assembly of solid elements whose two-way connections can either
- allow rotational movement around an axis (…)
- or allow one solid to rotate relative to another, around a point.
- Information system
- Embedded system
- “Complex” system
This great range of possibilities serves to underline the “arbitrary” aspect mentioned above, and is enough in itself to demonstrate what a challenge it would be to produce a generic definition of a system, and why it is preferable to adopt a tailored approach in order to reliably study a particular system, which, it might be argued, is what constitutes “systems engineering”.
2.2. Systems engineering
The literature provides definitions such as:
“Systems engineering covers the whole of the development of a system, and deals with the management of the transformation of needs, expectations and constraints within a product and supporting them throughout the life cycle of the product”(Chrissis-Konrad-Shrum 2003: CMMI – Guidelines for Process Integration and Product Improvement )
“Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems.” (Systems Engineering Handbook, INCOSE)
Before attempting to define “systems engineering”, I would like to quote from Jean-Louis le Moigne’s excellent work “Théorie du système général” (“General system theory”), which highlights so well that the notion of “system” is completely linked with the act of modelling, which is consciously non-neutral: “any representation is biased, not through oversight on the part of the modeller, but intentionally. … and to leave aside the illusory objectivity of comprehensively listing every element to be considered”.
This bias can be looked on as being the engineering context (analysis, design, implementation, verification, etc.) which leads us to consider our system, and to model it.
So one definition of systems engineering might be: “A set of functions, activities and techniques used in studying a system, the purpose of the study depending on the project context (implementation, operational maintenance, innovation, verification, etc.)”.
The problem when trying to formulate such a definition is that one can seem to be defining a different concept, in this case the concept of method as set out in existing definitions:
“a discipline that deals with the principles and techniques of scientific inquiry” (Merriam-Webster- http://www.merriam-webster.com/).
This definition refers to “inquiry”, which it is tempting to associate with the “intrinsic” knowledge of the specialisms affected by the purpose of the studied system.
« Scientific method refers to a body of techniques for investigating phenomena, acquiring new knowledge, or correcting and integrating previous knowledge » (Goldhaber, Alfred Scharff; Nieto, Michael Martin (January–March 2010), “Photon and graviton mass limits”, Rev. Mod. Phys. (American Physical Society) 82).
This definition, while more prosaic, is still more or less equivalent in that it refers to the concept of a body of knowledge about knowledge.
Without wanting to over-complicate the argument of this article, we may note in passing that systems engineering can also be considered as a body of methods (and good practices) tailored to the objectives which one wishes to achieve with regard to a system (developing, verifying, or maintaining it, etc).
3. Artifacts of systems engineering
3.1. Processes and information systems
A widespread good practice in systems engineering is to consider that:
- The engineering of a given system is guided by a context which also needs to be defined.
- A system is made up of a set of sub-systems, each of which is an entirely independent system.
- A system must be verified using an appropriate system (set of procedures and resources for verification).
Three basic interactive processes may be distinguished in systems engineering, and each of these processes will deal with its own artifacts:
- Requirements management (or context management), which is fundamental because it defines the elements which will enable us to guide and monitor the activities involved in engineering a system.
- Architecture, analysis and allocation, which is the core activity of systems engineering, in that it produces the modelling artifacts for the system under consideration.
- System governance, which deals with the decision-making elements of the project.
Carrying out these processes leads to an information system whose purpose is to manage the coherence of the artifacts processed during the life cycle of a system.
3.2. Cross-system traceability
As mentioned above, all systems (systems, subsystems and verification systems) have their own process and their own information system.
This is justified above all by the differences which may exist between these systems with regard to:
- the teams involved;
- delivery milestones;
- the level of maturity in engineering techniques;
- the resources (tools) to support the information system;
- the protection of industrial property on which some of the artifacts of a system may be based, by the organisation responsible for their engineering.
For these reasons it is important to maintain a system to provide traceability between the different information systems:
4. Standards and architecture frameworks in systems engineering
At this point in the article, dear reader, you may perhaps feel a little apprehensive faced with the huge task which deploying systems engineering seems to present; indeed, this would be entirely understandable, as it is inevitably an ambitious project.
However, there are numerous standards available to help you understand, disseminate and support systems engineering, which:
- specify the objectives which need to be reached when introducing systems engineering (and particularly the processes),
- and provide accepted terminology.
The main relevant international and industry standards according to the French chapter of the INCOSE, (AFIS:www.afis.fr) are as follows:
Derived from the military standard MIL STD 499B, this IEEE standard, first published in 1994, focuses on technical systems engineering processes from requirements analysis to physical system definition.
The three processes of requirements analysis, functional analysis, allocation and synthesis, are highly detailed, and each contain verification or validation sub-processes.
The aim of the system analysis process is to analyse problems (conflicting requirements or alternative solutions) arising from the main processes in a multidisciplinary framework in order to facilitate decision-making.
The Information Systems Control process relates particularly to the technical management of systems engineering and the control of both system and project information.
This EIA standard supplements technical system definition processes, covering product implementation through to go-live (user handover). It also includes contract processes for purchase and supply.
The technical and contractual processes are framed:
a) by management processes (in their traditional form with the three subprocesses of planning, assessment, management)
b) and by processes for evaluating the outputs of activities (verification process to verify that the activity was performed and validation process to verify that the output matches the requirement, these two processes together supplying evidence of conformity; together with system analysis processes covering choices made throughout the definition and thus optimisation of the system).
This ISO standard, which was inspired in its form by ISO/CEI 12207–AFNOR Z 67-150 (Typology of software life cycle processes), was first published in 2003 and reviewed in 2008: it extends technical processes to the whole system life cycle, covering operations, operational maintenance and end-of-life processes.
This standard applies to the engineering of contributing systems which have their own life cycle (e.g. manufacturing, deployment, logistical support and decommissioning systems): an example would be the engineering of dismantling and waste processing systems for a nuclear installation.
It supplements project-related processes with “business” processes and whose purpose is to develop the potential of the IS organisation by managing shared fields of activity to the benefit of IS projects.
Of course, there are other, more specifically-targeted standards, of which I shall cite just one example, relating to an area which is very fond of systems engineering techniques, namely aeronautical engineering: ARP4754A (Guidelines For Development Of Civil Aircraft and Systems).
4.2. Architecture frameworks
In addition to the standards focusing on “what”, there are also architecture frameworks, which deal with “how”.
Although these were only initially created for use with large projects, an architecture framework is essential in systems engineering and should always be present with a greater or lesser degree of formal definition depending on the project size within any organisation practising systems engineering.
An architecture framework enables one to specify/rationalise the resources which need to be implemented to control a systems engineering information system by setting a framework for describing an architecture and communicating/sharing around that architecture.
There even exists a standard defining what a system architecture should contain, and its associated framework: ISO/IEC/IEEE 42010 (see http://www.iso-architecture.org/ieee-1471/faq.html#wh42010).
However formally or informally your architecture framework may be defined, it is at least interesting to read this standard to get a good insight into what an architecture framework should be:
Here are a few examples of architecture frameworks:
Using these “as is” is only relevant for projects above a certain size. However, there is much to be gained from studying them.
5. Choosing deployment objectives
Now that we have the landscape of systems engineering in our mind, it is possible to start talking about deployment: deploying systems engineering in an organisation means setting up a toolkit (tools + methods).
This toolkit needs to be specified.
But before you specify your systems engineering toolkit, it is very important to set down what its guiding principles are:
5.1. Setting the guiding principles of a systems engineering toolkit
As systems engineering depends fundamentally on collaboration between the various specialisms involved in developing a system, it seems natural that the watchword for a systems engineering toolkit should be “communication”, and this should be the basis around which the guiding principles are defined:
5.1.1. Communication in the systems engineering toolkit
This comes down to selecting which basic process (requirements management, architecture, analysis and allocation, system governance) holds the artifacts which will mainly be exchanged between the specialisms involved in systems engineering.
A system engineering project with a large number of subcontractors all with very different specialisations will tend to select the “requirements management” process as the reference process.
The basic artifacts of communication between the various specialisms (here represented by the subcontractors) would be:
- Contractual engagement
- Formal justification.
An example of such a project might be the project to develop the future European air traffic management system.
By contrast, a systems engineering project with a smaller number of subcontractors, where the prime contractor is the main centre of specialisation, will tend to select the “architecture, analysis and allocation” process as the reference process.
The basic artifacts of communication between the various specialisms would be:
- CATIA part description file (.catpart)
- Geometry parameters
- Mesh control parameters
An example of such a project might be one to develop a vehicle chassis.
A systems engineering project developed using an “agile” approach, in other words deployed very regularly and progressively so as to validate/verify the system in the field before defining the next set of requirements, would tend to select the “system governance” process as the reference process.
The basic artifacts of communication between the various specialisms (in this case, types of user) would be:
- Performance measurements
- Anomaly reports
An example of such a project might be the implementation of paperless accident risk assessment procedures and contract management for an insurance company.
These three examples highlight three representative modes of systems engineering deployment which each have their strengths and weaknesses.
It should be noted that these modes are of course not mutually exclusive, and an ideal deployment of systems engineering would be a combination of these three modes.
5.1.2. Requirements-driven systems engineering
The concept of “requirement” is one which is easy to share, as it is very often associated with natural language and a consensus-based style of project documentation.
For this reason, organisations offer relatively little resistance to change when systems engineering is deployed in this mode.
Another aspect which makes this the most commonly chosen mode of deployment is that the need to deploy systems engineering in the organisation coincides with a new need on the contractual relationship management front (this may be with the organisation’s customers just as well as sub-contractors).
If there is one artifact that is well suited to support contract management, it is the requirement.
One factor which can hold back the application of systems engineering in this mode, particularly in southern Europe, is the perception that the implementation of requirements-led systems engineering is not sufficiently technical or practically-oriented, and that in any case, contracts and specifications have always been successfully produced up to now.
Implementing requirements-led systems engineering is thus perceived as an information system for quality and management teams, rather than as a tool for the systems engineer.
This attitude becomes less marked when an organisation is also faced with new challenges to do with setting up multi-project specifications and contracts (controlled reuse, management of product lines, sophisticated configuration management).
5.1.3. Model-driven systems engineering
This is the mode in which the greatest productivity gains can very clearly be obtained, which accounts for the buzz over the past ten years in the system engineering community around model-based systems engineering, or MBSE.
This mode takes its techniques and tools from the world of software engineering (model transformations, model annotation, meta-modelling, ontologies, information systems “urbanisation”, architecture frameworks), and has the advantage of being directly applicable to systems engineers in their day-to-day activities.
This mode of deployment also benefits from the marketing cachet of techniques with a high reputation (simulations, numerical models, etc.)
The flip side is that return on investment in this mode of deployment takes a relatively long time to realise:
- difficulty of obtaining consensus on the definition of business meta-models
- selection/customisation of different tools for each meta-model/business area
- inevitable need to redesign training on systems engineering processes.
This mode can of course be applied incrementally if a genuine systems engineering deployment plan is put together in advance and is part of the organisation’s master plan.
5.1.4. Feedback-driven systems engineering
This mode of deployment is extremely effective if the quality of the system can only be assessed effectively when it is used in practice, for example a system to implement paperless business processes, or if a system is developed using an “agile” approach (Scrum, etc.).
The watchword here is pragmatism, and feedback can be something very practical and reliable which very rapidly builds into a high-quality knowledge base.
This mode also has the advantage of being minimally intrusive with regard to existing systems engineering techniques.
However the danger is that one can lose control of this knowledge base if a clear strategy for its use is not defined.
Another negative aspect of a feedback-based approach is that feedback is generally “negative”. (People are naturally more inclined to say what doesn’t work, hoping that this will help to get things changed, than to say what works well.) Hence it is important that the deployment should provide means to encourage positive feedback.
In summary, this mode goes together with selecting the “system governance” process as the reference process; it is also very important not to confuse “governance” with “monitoring”.
5.1.5. Communicating the systems engineering toolkit within the organisation
This point is all too often underestimated.
Deploying systems engineering processes within an organisation requires a deployment plan to have been defined in advance, ideally as part of a master plan.
Without substantial internal communication about the project, and the value of the effort required from those involved in improving/introducing systems engineering processes is not made sufficiently clear, the odds are that as soon as systems engineers are under pressure to deliver, the deployment process will stagnate and may even degrade the efficiency of the processes.
6. Building the information system
Two types of information system architecture can be defined to support systems engineering:
In this architecture, one can focus on one or more aspects of systems engineering (requirements management; architecture, analysis and allocation; governance).
If this type of architecture is chosen, the tool selected to act as the backbone must have good facilities for:
- customisation, so that business tools can be integrated without difficulty;
- security, so that access and permissions for all stakeholders in the systems engineering can be efficiently managed;
- handling distributed data, as the information system must be prepared to deal with “transverse” data which is distributed over a number of servers, or at least accessible from different sites;
- traceability, so that the links between systems and sub-systems can be managed;
- configuration management, to provide efficient means to manage reuse and variability (product line management) of Systems engineering artifacts.
This architecture is unquestionably the most durable and the most reliable in the long run, but is relatively costly in the early phases of deployment, and requires substantial commitment from company management.
Here are a few tools (not an exhaustive list) which can be considered as “backbone” tools for this kind of architecture:
- DOORS (IBM)/IRQA (Visure)
- JAZZ/OSLC/RTC (IBM)
- E2KS (Emergent Systems)
- WindChill (PTC)/Enovia (3DS)
- GENESYS (Vitech)
6.2. “Host” architecture:
Another approach consists of selecting a tool which is fundametally oriented towards a particular aspect of systems engineering (requirements management, architecture, analysis and allocation, governance):
A “host” business tool must have sufficiently robust capabilities in the following areas:
- the tool should have modules offering a solution (even if cursory) for other aspects of systems engineering (requirements management, architecture, analysis and allocation, governance);
- good facilities for customisation and adaptation, so as to integrate other tools or modify existing functionality;
- good security features for data managed by the tool.
This architecture allows small-scale (project-oriented) deployment which may be relevant in that:
- deployment is based on a generally familiar business tool, which is generally centred on the “main” business line;
- deployment costs are generally better known and lower.
But it is important to keep in mind that such an architecture has its limitations with regard to adaptability:
- … when it comes to a wider deployment, and particularly where the day-to-day use of a tool designed for one specialism needs to be “sold” to other specialisms;
- … when the artifacts produced need to be reused, and variants managed.
Here are a few tools (not an exhaustive list) which can be considered as “host” business tools for this kind of architecture:
- CATIA V5 (3DS) / Creo (PTC)
- CATIA V6 (3DS)
- MATHLAB/SIMULINK (Mathworks)
- Rhapsody (IBM), Artisan Studio (IBM), Enterprise Architect (Sparx), Core (Vitech), etc.
To sum up, as has been seen throughout this article, deploying systems engineering within an organisation is an ambitious project which can be genuinely comparable to deploying an ERP system (SAP, Sage, Dynamic NAV, etc.), though instead of targeting the business’s management processes, system development processes are targeted.
Also, what is a business if not a system whose purpose is to produce wealth (for example by creating systems)? And here I must mention a product line (http://www.sap.com/lines-of-business/research-development/solutions-overview.epx) which would be a fundamental building block in implementing an information systems for systems engineering.
One must however keep clearly in mind the risks of such an approach:
- Concentrating too much on tools: despite the theme of this article which has steered the debate towards information systems and thus to the tools which process that information.
- Overlooking governance: governance, and governance alone, is at the core; when all is said and done, the information system which supports systems engineering should be seen as providing a means of governance for the decisions needed to develop a system.
- Running out of steam: without an underlying master plan, or at least a strong-willed senior management team; this kind of project often finds itself eroded by the short-term constraints of other projects directly financed by customers.