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.

ISSW.gif

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.

Bibliography
1. S. Alter (2003) 18 reasons why IT-reliant work-systems should replace the “IT-artifact” as the core subject matter of the IS field, Communications of the Association for Information Systems 12 (366-395).
2. J.B.M. Goossenaerts, A. Zegers, J.M. Smits (2009) A Multi-Level Model-Driven Regime for Value-Added Tax Compliance in ERP Systems, Computers in Industry 60 (709-727). available online at: http://dx.doi.org/10.1016/j.compind.2009.05.013
3. Boehm, B., Egyed, A., Kwan, J., Port, D., Shah, A. & Madachy, R. (1998) Applying the WinWin Spiral Model: a Case Study. IEEE Computer, July, 33-44.
4. Kruchten, P. (1995) Architectural Blueprints - The “4+1” View Model of Software Architecture, IEEE Software, November, 12 (6)