One does not tell a knowledge worker how to achieve a certain goal. That is the defining characteristic of knowledge work: such a worker needs to know his business. In contrast, a production worker can - and generally will be - instructed precisely how to act. A knowledge worker relies on his own judgement - that, and his knowledge and skills is actually why he is hired in the first place.
How can we support a knowledge worker with IT? The answer is not so obvious than it might seem at first sight. IT has invested, lock stock and barrel, into process design. But process design is created for production workers, not knowledge workers!
Obviously, a knowledge worker must take good note of a particular situation before acting. He has to know the situation, has to be aware of all ins and outs before deciding how to proceed. This holds for policemen, teachers, medical staff and what have you, alike. We call this *situational awareness*.
Perspectives are the Actions of Roles in Contexts
Carefully designed information technology can promote situational awareness. To provide the right information at the right moment - and not to overload a knowledge worker - is of paramount importance. Perspectives, as a method to create software, is designed for this purpose. The essence of a *user Perspective* is to provide exactly the information needed to judge and act. A user Perspective is a precise concept in Perspectives. It is the collection of Actions available to a user in a given Context. With a Perspective we express, nay, define, what information should be at a user's disposal and what information Actions he needs - given his goals.
From Business Actions to Information Actions
Perspectives-as-a-method guides you through the process of translating Business Actions into Information Actions. Information Actions are creating, consulting, updating and removing of information. Decomposing Business Actions into Information Actions is guided by a simple goal-directed principle. It all starts by formulating the goal of a user in a Context. For example, an employee in the shipping department wants to send an item to a customer. She needs to know about items that were sold. So here we have a Business Action - ship an article - that can be decomposed, firstly, into a Consulting Action (read the order). Now because of this Consulting Action, we need a Create Action for another user, in another context (the client that ordered the item while shopping). In other words, modelling is driven by Business Action needs. By this method, Perspectives aligns Business with IT by modelling the Information Actions that users must be able to perform, given their goals and responsibilities.
Actions demand a particular View on Roles
Consider the static structure of a Perspectives model, consisting of contexts and roles. The structural part is made up of Contexts, with various kinds of relations (such as embedding) and Roles (a Role belongs to a single Context). The familiar information world of numbers, strings, booleans etcetera all falls in the category of Properties of Roles (remember, not just users are represented with Roles: things are, too).
Roles may have many properties that are irrelevant for a given Action. This is expressed in terms of a *View*. A View is nothing more than a selection of Properties of a Role. We associate Views with Roles. But we also qualify the subject and object of an Action with Views (an Action is a Subject-Verb-Object sentence). This works as a constraint on Role-filling for an action. For example, if we wish to send a letter, the Object Role in the Action can only be filled with Roles that have an Address View. Clearly, a Person would fit the bill, but a shoe would not.
When a user executes an Action, a complete description of that Action is stored in his local database (this is an option). These Actions are not communicated with other users. This Action trail describes, without loss of information, the entire history of the user's behaviour. It forms a database that could be mined for all sorts of purposes, such as learning from the user's behaviour to automatically configure his system. Aggregated over many users, we have a pool of behavioural information that could be very useful for all kinds of analysis. Obviously, this creates a market for data, where, for once, the originators of that data - the end users - have the upper hand. Contrast this with the barely legal data collecting executed by many of the big names on the web!