How to Implement Symbolic representations

Objectives

As far as systems are concerned, symbolic representations will have to be physically implemented, whatever the technology, clay or digits, papyrus or holograms.

How to implement symbolic representations

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.

System components are first characterized by what they can do: dealing with physical contingencies, processing symbolic representations, taking responsibility.

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.

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.

Requirements are partial, biased, and volatile.

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:

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.

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