Chapter: techno order overview
Ontologies of other orders: natural order, social order
The Work System Context
The techno order is ICT-reliant[1]. A contemporary change initiative must take into consideration a variety of specifications (expressed as models), data (captured in data bases and content systems), software systems, and hardware systems [2]. These must be used and/or the evolved work system must inter-operate with them.
The context evolves over time as the outcomes of much simultaneous action accumulates.
Model-based Engineering
For scoping and implementing change to an existing work system (part of the physical view) we adopt model-based engineering combining elements of Boehm’s Win-win Spiral model [3] and Kruchten’s 4+1 view model [4] of (software) systems architecture.
This figure distinguishes three views to structure the adaptive cycle of IT-reliant work systems: the Conceptual view (CV) with three sub-views: logical, interaction and integration; the Physical view (PV) in which the operational entities and their material and conceptual objects exist; and the Development view (DV).
In the figure there is an existing work system (AS-IS) with identified stakeholder needs. Then the re-engineering or change of the work system is model enabled: stakeholder needs are identified. During an analysis phase these needs are anchored in the conceptual view of the system's baseline. A blueprint is defined as a specification "on-top-of" the baseline. Often the blueprint will include refinements in the logical and interaction view. After the blueprint has been approved by the stakeholders, development and implementation will deliver the TO-BE physical realization responding to the identified stakeholder needs.
In all views one should pursue incremental change to assets that have been accumulated over time. Moreover one should ensure that the end-users drive the ICT capability acquisition.
Operations, Maintenance and Development
This figure shows the life cycle stages (System Development and System Operation and Maintenance) that involve the "real site work system." The life cycle foci Primary Process & Asset Maintenance and Project Execution materially affect the real site work system. The life cycle foci Evaluation & Monitoring and Project Portfolio Management (PPM) have a "roundabout character." A performance alert will notify PPM of a (performance) problem.
Project Execution Scripts
Assuming that PPM has allocated the task of solving a set of problems, then project execution can choose from a range of scripts. Well known scripts are those of Model-Driven Development, Rapid Application Development, Commercial-of-the-Shelf (COTS) implementation or System Maintenance.
In this figure three project scripts, V1, V2 and V3 are coloured and named according to their technological depth, as reflected in the repository models and model increments that the scripts will use and deliver. For the real site work system there is one Work System Repository. Each project proceeds by adding a model increment ( the \ slope) and by implementing this ( the / slope).V1: Direct Decision
This script the decision making primarily rests upon the value and risk model for the different stakeholders. Three steps are typical: D1.Scope Definition, D2.Decision Analysis and D3.Installation & Delivery.
V2: Operations Project
In this script, the decision making rests upon the value and risk model for the different stakeholders, and a detailed model of the operations and exchanges in which these stakeholders interact.
In addition to the V1 activities, renamed O1 and O5, there are O2.Problem Analysis, O3.Decision Analysis and O4.Construction & Testing.
V3: ICT-reliant Work System Project
In this script also the ICT systems will be involved. In addition to the V1 and V2 activities renamed as I1, I2, I7 and I8, there are I3.Requirements Analysis, I4.Logical Design, I5.Decision and I6.Physical Design & Integration.
The Multi-level Perspective
Until this point, and except in the first figure, we have not yet indicated the level of the work system that is considered. As the technological depth of change increases (V2 and V3 project scripts), there are good reasons to avoid that wheels must be invented over and over again. Often it will be possible to buy a reasonably priced solution on the market. However in the case of complex Actor Networks, change may involve a large number of existing stakeholders and components in the work system. In such situations it will be important to express required changes precisely. Doing this singly and severally will still inflate overall costs. This is one reason why the multi-level model-driven regime has been introduced [2]. Such regime creates opportunities of model reuse across levels and principals, or lean enterprise architecture, society wide.