In the Encyclopaedia of Computer Science [ECS93] we find the following definition of an Operating System (OS) and its design goal:
".. a set of software extensions of primitive software, culminating in a virtual machine that serves as high-level programming environment and manages the flow of work within a network of computers".
This definition emphasises the close connection between hardware and that bulk of software called OS. It does not reflect the interests of people who have to work with such systems directly and I have a preference to the following more general definition, as it is stated in [PBH73 ]:

The appealing aspect of this definition is

1. it includes people who are affected, independent of being customers or persons operating directly on a computer. The primary goal of an operating system therefore is convenience for the user. The definition focuses on the overall purpose of an OS leaving technical aspects aside and does not refer to implementation and structural details.
2. if one regards "procedure" in the more general and original meaning, it also includes any action, which contributes to the purpose of the system directly, regardless of whether this action is performed by means of a computer or by using other resources including actions initiated by users.

As a consequence we could look at an OS from its (human) clients point of view. Then we can make a classification of OS depending on the mode of operations they are providing, e.g. batch processing, time sharing, distributed processing etc. and can discuss which modes are more or less suited to the individual needs of the customers.

This immediately leads to the analogy between an OS and the organisation of a company. We will use operating systems as models for such organisational aspects. The most suitable organisation has to be chosen depending on the needs of customers and according to the mission of a company. On the other hand, a given organisation specifies and restricts the way customers have access to the company and how employees can interact internally in order to fulfil their tasks. Later on we explain, why Client Server oriented architectures are especially suitable to be used as convenient models for mastering business processes. This point of view will be discussed in the sequel.

The term 'Teleworking' (TW) is a very broad scale expression and naturally there is no unique definition. It can mean taking employees out of the workplace and putting them back in their homes. But this restricted view refers rather to what is called home working. TW can mean transferring back-office work to remote data processing centers or outsourcing it altogether. In the latter case however the relationship between the company and its employees is weakened or terminated. In any case TW uses information and communication technologies to practice remote working of some kind. So telework - as it is understood currently- is not an occupation of its own, but a method of working and is developing as technologies develop. In the last chapter (5) we come back to this interpretation and we will promote a more general view, understanding TW as profession of its own too. Another important feature of teleworking is flexibility in the sense of flexible staffing and recruiting from a wider labour pool and to cope efficiently with fluctuating workloads.

A very broad definition or rather description of TW and therefore commonly accepted is as follows:

Teleworking persons (TWP) work partially within the company ´s office space and partially outside at their home office and they have to interact with either group, other TWPs and colleagues who do their job in the traditional way. The definition leaves open when, to what extent and where this distributed work is done.

We see, that TW refers – from a narrow point of view - to the "mode of operation" of employees of a company and the "interfaces" between the individual workers. If we want to address TWP who are acting as self-employed persons we have to expand this view to more general aspects focusing on "changing the geography of work" and on the implied communication paths.

In the sequel we want to discuss the following related aspects in particular:

• Assuming a hierarchical organisation structure for companies as the most common one, based on "functions" (i.e.: purposes of the departments), does it meet the needs of TW or has the management to restructure a company radically as soon as TW is implemented? Is such an organisation suitable if workload and efficiency of TWPs has to be measured?
• To what extent is the evolution of OS mirroring the mutual needs of people and companies? Which analogies between the internal structures of an OS and the structures of a company can be drawn? Can we learn from the experiences drawn from the evolution of OS?

At the very beginning there was no distinction between what we call system software today and between programs, which are user supplied in order to perform some application on a computer. So let us make a big jump into the late 1950s and early 1960s, when OS started already to exist.

The following aspects characterise the systems of that time:

1. there is just one processor and in particular one common system clock
2. batch oriented processing of tasks was dominating.

Later on the concept of spooling was brought in by the use of interrupts and by providing the possibility of overlapped task execution, as long as they are independent from each other. This brought in additional problems followed by an extensive discussion on how to synchronise parallel processes.

Although there was now a clear distinction between system oriented tasks grouped together as what we would regard as an OS versus user oriented tasks, the situation was still uncomfortable in the following sense:
Because such early OS were more or less unstructured and programmed like spaghetti code, there was no strict separation between the individual sub tasks an OS had to perform. At any time any subcode of the OS could invoke any other part of the OS. As a consequence running a user program always required the whole OS to be loaded in advance.

If one transfers this situation into a task an employee has to do, we can recognise:
if an enterprise is unstructured as monolithic OS are, then no person could take away even primarily isolated tasks in order to perform them somewhere outside of the company. Whenever there is a need to have access to the company’s resources it is very likely that access to other resources and extensive communication with co-workers including frequent synchronisation would be necessary. The amount of these interactions can not be predicted. In this scenario TW might not be possible at all or could cause troubles.

However, focusing now on the structure of an OS and its logical design, we are interested in concepts in order to improve the reliability of such systems and to improve its internal structure.
A major step in the evolution of OS was the idea of structuring them into layers. This was a direct reflection of general concepts of software design, better known as "stepwise refinement", "information hiding principles" or generally "structured design of software".
The various layers are separated from each other as much as possible and information exchange between the various layers is provided by a defined interface.
In particular the interface between the OS itself and the user program becomes relevant: the Application Interface (API).
Depending on the Operating system these interfaces were weak or strict and the best known layered approach we can find in the literature are implemented in the THE operating system [Dijkstra1968] or the Venus System [Liskov1972].

If we transfer this layered approach directly to companies and the way they are structured we observe:

There is a well defined structure in the company and typically it is a hierarchical one. It provides layers and the components of its layers - the nodes of the resulting hierarchy, also called organisational chart or organigramm for short - are responsible for doing some specific and well defined task. Each component (department, functional section) may delegate tasks to nodes below or may call for assistance to nodes of the lower level layers too. The communication and therefore the way how data is submitted to or returned by the various interacting departments is standardised usually by the use of well-defined forms. An association with the API of an OS comes into mind immediately.

From OS we can learn, that this approach is not as efficient as it is supposed to be. A strict separation and the resulting interfaces work fine in theory, but in practice there are intrinsic problems derived from the demand that the layers should be arranged treelike reflecting a true and consistent hierarchy for all the needed functions.

A typical example for such intrinsic difficulties is given by a File System. A File System should hide the underlying mass storage architecture from application programs, which must have access to data stored on the disks. The File System also should be replaceable by another one (think of FAT- file system and the NTFS used within the Windows NT- Operating system). Consequently the File system should be rather on top of the software hierarchy. At the same time, the OS itself, using virtual memory management must allow some of its low level components, the kernel and/or device drivers, to have access to the main memory extensions held temporarily on the disk, e.g. by paging techniques. Consequently the file system must be subdivided into a low-level component and a portable part located rather on top of the hierarchy. This increases the number of interfaces and slows down performance because of the overhead. The low-level component itself must have access to system dependent drivers and is probably placed somewhere else within the overall structure and a strict tree can not be maintained.

Another weakness is the emphasis on a static view: which functions are allowed to call other functions directly. But OS have to control the co-operation of processes and this implies other organisational structures, which are more suitable to handle such a co-operation and to synchronise sequences of events
Think of the following example. A new employee has to be hired. A lengthy list of departments and various subdivisions of a hierarchically and functionally organised company is getting involved in handling this matter. The following activities have to be done among others: specifying the required skills, advertising, interviewing and testing, registration for insurance, preparing everything for the payroll, assigning for training, allocating office workspace, opening computer accounts etc. It is likely that the "advertising task group", normally responsible for placing advertisements for product promotion will belong to a different branch of the organisation from that to which the IT department belongs. It is the IT department which is responsible for providing the IT resources to the new staff member. It will take some time and extra effort until the new staff member file gets all the endorsements and it can be transferred to the IT group with the instruction to open a new account for the domain in question. People from the advertising task force cannot give orders to the IT- group and the same is true for the interaction between the general administration, which is handling the payroll matters, and the division which prepares and organises training courses. So the file goes up and down the hierarchies and provokes many interactions, which are a result of the underlying organisational structure instead of obvious and task oriented needs only.

Transferring this again to the situation of a TW we find: if an company is organised strictly in a hierarchical manner and if the (static) functions of its units are the dominating organisational aspects, then we encounter similar problems as they exist in designing the interfaces for a hierarchical OS. There are too many needs for access to other units when climbing up and down the various levels and many of these steps are necessary because of the chosen organisation rather than by the real needs of the case in question. Many interfaces and time consuming interactions are involved. This reduces the degree of flexibility of TW and its potential power. The frequent need for interaction with others demands people to work within the company where these interactions occur. The number and kind of tasks, which can be performed by TW remains restricted and may inhibit TW completely.
We will achieve a substantial change if we adopt the following process oriented approach:
Declare an experienced and reliable staff member as responsible for the task "hiring a new employee " and give him or her the rights ("privilege") and authorisation to call for assistance from other task oriented groups whenever it is necessary. This person attends to the matter from its very beginning up to the final event of welcoming the new employee. In other words, assign the privilege to act as a client and call for the services of others in order to fulfil the initiated task, create the process "hire people". We come back to this approach in the next chapter.

As we have pointed out already, organising an OS purely from a static point of view means: ignoring running processes in favour of their static descriptions, which are called programs. Comparing this against organisational forms for companies we can recognise: a functional and in particular hierarchical organisation structure reflects a static view. It is not process related. It shares the same problems as we have mentioned for hierarchically structured OS.

In order to overcome these problems two closely related tendencies can be mentioned:

As described in [MUE98] process orientation of companies is a feasible way in order to enable TW and to bypass many problems, which would occur, if TW were forced onto a hierarchically organised and functionally oriented organisation without any further restructuring. The above example "hiring a new staff member" exactly reflects this observation.

Therefore we recall major concepts of such design principles for distributed operating systems, in particular those, which provide interesting analogies to TW within a business process oriented company. It is sufficient to recall the principles of client server oriented systems, which do not fulfil all the general criteria characterising a true, distributed OS. However we can learn from the experiences made and solutions provided for client server architectures, because there are many analogies to business processes.
The idea behind such a client server model is to view the OS as a group of co-operating processes exchanging timing signals and such like. Some of them, called servers, offer services to others, called clients. Whether a process is a server or a client is not a permanent property, it depends only on the (changing) relation " server offers and performs a service demanded by a client".

The distributed components of a client server oriented OS are organised in order to perform sub processes autonomously and in parallel. Whenever a process has to interact with another process, it does this by sending messages via a kernel by means of e.g. Remote Procedure Calls (RPC) or directly by Local Procedure Calls (LPC) exchanging a minimum amount of data. The specification of RPCs also includes protocols used to send data over a network.

Figure 3 shows a situation where clients and servers run upon one processor and communicate via just one kernel. However the general model leaves open, whether there are more (identical) kernels and the servers and clients are distributed and linked together by a network, as it is shown
in Figure 2.

One major point is that the exchange of signals and the RPC mechanisms enable the subsystems responsible for performing the various tasks to be run elsewhere.

If such processes run within the system, which hosts the kernel too, then they share a common clock and the same physical main memory. In this case synchronisation is easier and also the complex remote procedure call mechanisms can be replaced by the faster and slimmer LPCs because of the underlying reliability and because of reduced security concerns. These LPCs even can bypass the controlling OS kernel and may send signals and messages directly to other subsystems residing on the same host.

If subsystems are located outside, driven by other processes and neither sharing the hosts memory nor having a common clock, than the Remote Procedure Call mechanisms provide the desired interfaces for communication and acknowledgements of submitted data. (We restrict the discussion to RPCs and do not discuss here more advanced concepts for what are called Object Request Brokers, as there are OLE, ActiveX or the CORBA specifications)

In either case processes run in parallel, exchange signals, data or references (pointers) to data as sparingly as possible but as much as necessary to cover all essential security aspects.

We find that the C/S paradigm is ideally suited to TW as well. Let us regard a company as an environment providing a collection of business processes. We also leave open where these processes are performed, locally or somehow distributed. From this point of view remote processes are performed by TWPs and these persons have to communicate with others analogously to the C/S model. Interacting protocols and conventions have to be provided too. Specific communication paths have to be made available for dislocated remote work, but people should work autonomously as much as possible and should try to minimise the need for exchange of data and synchronisation signals.

The C/S paradigm defines clearly "client" and "server" but it does not say that a piece of software always is of type "client" or is of type "server" for ever. Although some software typically runs as a client (e.g.: mailing program) demanding processes from a dedicated server (e.g.: mail server), the attitude or even the mutual relationship between two pieces of software may change also. In the case of TW we find a similar situation. Co-workers as clients hand over a task to a TWP demanding a specified service. But the TWP in turn, now acting as a client, may need and ask for services of other co-workers independently of whether these services are provided by other TWPs or traditionally within the company’s office area.

The overall and main message is: clients demand the performance of business processes by servers and both sides rely on well-defined communication paths. Introducing TW therefore presupposes process orientation and an appropriate computing environment as well. We come back to this in chapter 4.2 again.

There is much more that we can learn from the history of operating systems. When Windows 3.x was implemented the designer had to obey backward compatibility to the former DOS operating system at any price. Although Windows 3.x was successful from the commercial point of view it failed in terms of structure, efficiency and stability and many customers had to suffer from its structural deficiency. So to speak: putting Windows 3.x on top of and partially aside DOS is a crippled approach. To some extent the situation remained unchanged when Windows 95 was announced and brought into the market. The intrinsic problem is that the specification and implementation process did not start from scratch or by means of a radical redesign. The commercial conditions have forced the developers to take compromises and the results are well known. However concerning Windows NT, the situation is entirely different. This operating system is based on a radical new design giving up a strict backward compatibility to any predecessors and basically is oriented on Client Server philosophy.

As stated before already, we regard the CS concept as a convenient and suitable model for TW. But we can also learn from the evolutionary steps the various systems went through:

On the one hand there are various technical and structural needs, on the other hand there are customers and clients who have a preference for stepwise changes. Providers are interested in a sound technical solution as a necessary precondition for long term success on the market and return of investment, users are anxious for new versatile systems whilst hesitating to accept the accompanying changes. Figure 4 shows the structure of Win 3.x and its structural deficiencies.

Principally a radical process oriented redesign would end up in changes of organisational structures from hierarchical to flat. But commercial aspects do also count and acceptance by customers must not be ignored. Both arguments suggest a smoother approach towards the right direction. If we transfer these observations to TW we find: TW demands process orientation in the longer run and therefore a company introducing TW must be prepared to undergo a business process redesign in order to avoid a crippled and inefficient internal structure. But all these approaches have to be prepared carefully and must be done stepwise in order to lead towards a feasible solution which is equally accepted by all partners: the employees and the employers as well.

Currently the major demand for TW oriented jobs comes from people expecting more convenient working conditions, e.g. reduced travelling costs and/or time spent for daily commuting or flexible arrangement of working hours due to individual demands and needs. Therefore they are prepared to accept changed working profiles too. But such changes also affect all the co-workers who still want to do their job as usual within the company.
As far as the management of a company is concerned we have to observe:
as long as there are no more convincing arguments backing the claim that introducing TW to the company would also improve the overall performance on the market, employers will hesitate to create and provide TW- oriented environments.
Approaches to push TW just by augmenting the demand for TW will have limited success, as long as the supply of such jobs from companies is not increased. The management of companies must have good reasons to make steps toward that direction. Many of the listed or reported benefits of TW for employers are compensated by other disadvantages and are, as a matter of fact, not really convincing. For an extensive discussion of these problems the reader is referred to ([MUE98], [SONN97]).

The answer to the revealed dilemma is: first a company has to reengineer its business processes, mainly for commercial reasons.
Reengineering a company’s business processes ultimately changes practically everything about the company, because all these aspects - people, jobs, managers and values- are linked together.

Hammer [HAMM93] refers to it as "the business system diamond" and visualises these interdependencies by the following diagram:

Such a reengineering process provides chances and opportunities to create those dedicated business processes that are suitable to be fulfilled by TWPs ideally and are in the interest of the company at the same time. The reengineering process also alters the management system, in particular the measures by which the performance of employees – teleworkers - is evaluated, which is necessary as soon TWPs do their job remotely and therefore are selforganised to some degree.
If we put all arguments together, we can conclude at this point: a radical redesign in terms of BR would be ideal in terms of structure and processes filtered out to be suitable for TW. But the success of Windows 3.x through an evolutionary approach teaches us to pursue a more evolutionary approach while having the overall target in mind. Each of the steps must establish a new TW-oriented process but must not ignore the implied structural changes and related side-effects.

In this section we come back to the remarks made in chapter 1.2. We reconsider the common view and statement that TW refers to "a method of working".
Probably the following lines are controversial, because I state that TW tends to be a profession of its own demanding special skills, attitudes and therefore a specific curriculum too. Of course one must not ignore the application where a TWP is doing his or her task. The emphasis must lie in a combination of both: general knowledge in TW and special skills in the demanded application area.

Let me start reviewing what we mean and understand as the profession "programmer". We can classify this into application programmers, systems programmers or we could have a preference for a more general description e.g. "software engineer". We could even distinguish between a COBOL programmer and a C programmer and implicitly, because of the close connection between the programming language in use and its related application area, we would also emphasise a specialisation in an application field. However, any primary training in programming emphasises skills and experiences, which are common to all types of programming areas. The qualifications demanded are independent of the application area which programmers will be faced with later on. This in particular is the major didactical argument, that distinguished programming languages- most of them belong to the PASCAL family- are chosen as primary programming vehicles despite the legacy COBOL. C, C++ and JAVA are the programming languages of the "real world" today.

Considering management training programs we can make similar observations. Such programs address managers of all kinds independent from products and activities these mangers are involved. An educational program for managers contains (among others) subjects such as motivating people, self-organisation and making plans, budgeting, communication training and, of course, skills in using common standard software.

If we transfer these observations to our particular concern, what are the skills and knowledge with which TWPs should be fully conversant, we can start a list of subjects without having any intention, to propose a mature curriculum:

• experience in self-organisation
• project organisation
• mastering communication tools
• bookkeeping
• common standard software (whatever this might cover)
• ……….

And this list has to be expanded, as soon we want to address people who want to start as self-employed teleworkers.

Imagine that you are an employer and a business process engineering procedure has filtered out tasks, which can be done better by TWPs. What would you be looking for: a person who is acquainted with the particular area of application but needs a full training program in order to master this by teleworking? Or, thinking of training costs, would you rather have a preference for an experienced TW who is prepared to step into the specific field of the intended application? From your company’s point of view in many cases it is easier or less expensive to train candidates in the application field.
There is a very appealing initiative in Europe, called "the European computer driving license" ([ECDL97]). Currently this ECDL consists of the following basic modules:

1. Basic Concepts of Information Technology
   (Hard/Software, security&copyright, LAN/WAN, Email, Internet, workgroups)
2. Using a Computer and Managing Files
   (file-management, directories, printing, editor)
3. Word Processing (necessary basics of formatting text)
4. Spreadsheets (as above)
5. Databases/Filing Systems (creating datas and formulas)
6. Presentations and drawing
7. Information Network Services

and I suggest we expand this list of subjects towards skills, which are application independent but essential for (the) future (of) teleworkers.

A good question is how to instruct people in an 'application' field which currently is unknown or not developed so far. In this particular situation we have to concentrate on general teleworking skills, regarding them as knowledge in a 'meta profession'.

It might be an academic discussion, whether TW is a profession of its own or if it is just a new way to perform tasks. But when we accept the necessity of additional skills and if it is clear, that TWPs have to perform well defined business processes autonomously as much as possible, then we have to train such people in dedicated skills and specific knowledge. Teleworking is much more than just allowing people to stay at home while doing a job.

Teleworking starts together with a business reengineering process and the processes filtered out are performed by persons who do not hesitate to work independently and are able to use modern communication tools and a set of standard software.

The author debits thanks to Michael Schröder for his valuable contributions and critical discussions.