Objectives
As far as systems are concerned, symbolic representations will have to be physically implemented, whatever the technology, clay or digits, papyrus or holograms.
System engineering processes will therefore have to consider:
- The context under consideration and the business processes to be supported
- How the system is expected to support those processes
- The symbolic representations to be used for that purpose
- The physical implementation of those symbolic representations.
Systems
Systems are designed and built to support human activities. At any given time they combine human agents with mechanical devices and symbolic machines. From an organizational point of view, the distinction is based upon two criteria:
- Responsibility: only human beings are meant to take decisions because electronic agents cannot be held accountable for the automated choices they may make.
- Rationality: since organizations can only be defined by words, a clear-cut distinction is required between symbolic and non symbolic processing.
The distinction between those functional categories is the starting point of system architecture.
From Problems to Solutions
System engineering cannot be reduced to a simplistic dichotomy of problem and solution as it must solve three very different problems:
- Business ones, e.g how to assess insurance premiums or compute missile trajectory. Business processes are meant to deal with business objectives.
- Functional ones, how the system under consideration should help solving business problems. Use cases are widely used to describe how systems are to support business processes, and system functionalities are combined to realize use cases.
- Technical ones, i.e how the system may achieve targeted functionalities for different users, within distributed locations, under economic constraints on performances and resources. Applications are implemented by system components depending on platforms.
Ideally, those problem and solution levels should be mapped to modeling and architectural layers:
- Architectures: enterprise (concepts), systems (functionalities), and platforms (technologies).
- Models: conceptual (business context and organization), analysis (symbolic representations), design (physical implementation).
From Requirements to Deployment
System requirements deal with borders, more precisely they describe how components are meant to interact. They are necessarily actual (at such an early stage nothing should be assumed about abstract symbolic representations), partial and biased (business concerns are necessarily specific and volatile). While requirements are to be concrete, i.e associated with actual business objects and processes, they don’t have to be fully detailed providing that additions or changes can be achieved locally, i.e without impacting on core functional units.
Design models describe the symbolic representations to be implemented as software components. They are also actual but they target system components instead of business objects. Eventually they are to provide full descriptions, but completion can be achieved by dedicated tools.
As should be expected, the difficulty lies in between, namely with transition (from business to system) and continuity (when business and technology change). As far as the consistency and continuity of symbolic representations are concerned, we need to consider the functional architecture, namely:
- The identity and semantics of business objects whose persistency and consistency are to be maintained independently of business opportunities.
- Business procedures whose semantics are bound to corporate identity and regulatory contexts.
Engineering Processes
System engineering can be seen through models or through tasks. The waterfall approach identify four (or five) steps:
- Requirements deal with business objects and processes.
- Analysis models describe symbolic representations.
- Design models describe system objects implementing symbolic representations.
- Deployment models describe the resources used to manage system objects.
The layered approach introduced by the OMG is slightly different but is set within the same paradigm:
- Computation Independent Models
- Platform Independent Models
- Platform Specific Models
Model layers can be interpreted as a waterfall or as a network. Following the waterfall paradigm, layers are derived from their predecessors by a mix of automated or designed transformation. The proposed approach introduces a shift in paradigm as it combines a business perspective with a waterfall, i.e engineering, one:
- The business perspective is synchronic as it deals with the representation of context objects and processes by system symbolic objects. Since objectives, constraints, and risks change along their own time-frames, their symbolic representations must do the same; as a consequence system requirements must be continuously and consistently anchored to business contexts.
- The engineering perspective is diachronic as it deals with the implementation of system components. Once rooted into requirements, the design and implementation of symbolic representations are only concerned with the life cycle of development artifacts.
In between the architecture perspective is meant to be as invariant as core business concerns and corporate identities, and the main challenge is to organize engineering processes accordingly. And that can be achieved if engineering processes are built bottom-up from work units depending on targeted outcomes.
Those are defined along two criteria, which give four workshops:
- Requirements regarding physical objects and agents, including systems.
- Requirements regarding processes, including system ones.
- Symbolic representation of persistent objects.
- Symbolic representation of transient objects.
It must be noted that such an organization put the focus on system architecture while analysis and design are regrouped within the same workshop. As a consequence, and once architectural concerns have been dealt with, agile methodologies can be safely pursued within workshops.
The proposed approach entails clear benefits regarding:
- Traceability, which is a prerequisite for streamlined engineering (product), portfolio and risk management (project), and application life-cycle management (process).
- Measurement, with built-in unbiased estimators, project workloads, and process assessment.
- Quality management, supported by layered traceability and objective measurements, with built-in controls, non-regressive testing, and model-based validation.
- Reuse, which provides another path to quality, with services (architectures), patterns (product), profiles (project) and development strategies (processes).
- Finally, collaboration is to be facilitated between engineering processes targeting heterogeneous platforms, using different methodologies, across independent organizations.