IT rests on the assumption that information carries meaning. While we won’t contest this as such, we’ll argue that the meaning of information depends on context. Within the framework of Perspectives, we can give this undeniable truth precise, technical footing. Compared to current practice, we approach IT from the rear by starting to think about roles, rather than first model information and only later add authorisation.

Information

Usage of the English noun “information” did not change between 1800 and 1940. In the next 60 years it’s occurrence in texts tripled. 

“Information” has the Latin verb informare as its root. Loosely translated this means “to shape”, in the sense of “I try to shape my thoughts”. I will hold that information is a thought in a shape. 

What shape? The primal form of a thought is without doubt the word. The spoken word, to wit. The objective of the spoken word is to exchange thoughts. That is what we call “communication” and its Latin root is the verb communicare, that we can translate with “to share”. Summing up: we shape our thoughts in order to share them (another objective of shaping your thoughts is to achieve insight. This can be a solitary excercise).

The invention of writing allowed us to give our thoughts a new shape. Clay, paper, walls, a wet sandy beach: all sorts of things can be written on. Such forms are clearly physical. A thing is scratched on, painted on, written on. Obviously the spoken word is physical, too: sound waves are vibrating air. The difference between the spoken word and a letter is that the latter will persist so much longer. Ever since the invention of writing the powers that be have had their thoughts incised on stone, in order to share them for centuries to come. Well, to impose them, really. This persistent form exposed our thoughts to two strongly interdependent effects:

1. A thought might be picked up by people not meant to;
2. it’s shape might be interpreted differently by such people (wrongly attributing this other meaning to the original source).

A letter can fall into the wrong hands, having unpleasant consequences for those involved. Moreover, words will acquire a different meaning once outside their original context. Both effects are strongly embedded in our culture. For example, we have invented numerous ways to prevent messages from falling into the wrong hands, from wax seals to ciphers to reliable couriers and mathematical cryptography. These efforts notwithstanding, each of us has been confronted with something we said but that, out of its context, suggests unintended nastiness.

The rise of Information Technology (IT) has given both problems a new urgency. It has become so much easier to copy and spread information – the form. So much so that the speaker has been relegated to the background in favour of his word. “Information” has become independent: the thought has been separated from the thinker.

The Information Technology Industry (IT Industry or just IT) understands information as something with meaning. I write ‘something’ on purpose, not ‘a thing’. Information is losing its physical character, to us: it has become meta-physical. A prime example is the wordt information carrier, as in hard disc or usb stick. Obviously, these are physical things that we have inscribed with our thoughts. So ‘information carrier’ is  a pleonasm: the carrying of a thought is already implied by ‘information’. Hence, the name ‘thought carrier’ would be more appropriate – or, indeed, just ‘information’. But it appears that ‘information’ is becoming a synonym of ‘thought’.

Nowadays one hears people speak of ‘the information in a letter’, where, obviously, the letter itself is information. We have started to confuse form and content, fundamentally.

If someone tells you: “I think he is right” and you don’t understand him, you will ask him: “What do you mean?” It’s about the thought, the intention, not the words. But when confronted with information we don’t understand on a screen, we’ll ask: “what is the meaning of this?” We experience meaning as a property of information, or its projection. Figure and ground trade places here.

Instead of inquiring at the source, we try to work out the meaning of available information. But isn’t it all about the thought the source tries to share? The speaker and his thoughts are the figure, belong to the foreground. It’s about his intentions. When we ask for the meaning of information, information itself takes the foreground while the speaker disappears into the background. Information stands alone, becomes independent.

This shift is relevant because we’ve constructed information technology such that information flies all around the world while it’s source is left behind. And that information, out of its original context, out of reach of its source that would be able to explain his thoughts, acquires all sorts of meanings. The larger the conceptual distance between the receiver and the source, the larger this shift in meaning.

All this follows from our current understanding that holds that information is in the letter itself. Whoever has the information, has the meaning, the thought. Information is the new gold.

System Integration

The IT industry started automating the financial administration of organisations, in the sixties and seventies. Over time other facets of organisations were automated, too, like human resources, the purchasing department, fleet management, etcetera. Each department acquired its own programs and over time the area covered by these programs increased, until they started overlapping. Employees are paid salaries; purchases are done under the auspices of employees and require finances, etc. Finance, Human Resource Management, Inventory Management: these are all projections of an organisation onto a specific facet. In daily life everything is connected, of course. So programs had to be connected, too.

This integration was a haphazard, tedious and difficult. Importantly, each facet was automated from the conceptual point of view of the professionals that were involved. They spoke their thoughts and IT gave them shape. However, a single entity figures in various facets. An Employee is a unit for Human Resources (contract, education, terms of employment), for Finance (salary, expenses) and for Planning (skills, availability). IT drew up shapes for each facet of the very same entity and quite often no a priori effort was made to make them work together.

These problems can be subtle and go unnoticed for a long time. When working for Dutch National Rail, I encountered an example in the concept of ‘platform’

Note to the English reader: in Dutch, there are no separate words for ‘platform’ and ‘track’. When trying to be specific, one could speak of a ‘platform-track’; but usually the same word, ‘spoor’ is used for both concepts. This obviously added to the confusion described here. To somewhat convey that feeling of confusion, I’ll use the Dutch word in this text.

A spoor is where passengers board the train. To those who draw up the timetables, a spoor is the sign where the train operator stops. However, to those who plan the allocation of rolling stock, a spoor primarily is a length (the longer the spoor, the longer the train, the more passengers will fit in). These two meanings given to the word spoor seem to complement each other. However, the fact that a spoor (as a platorm) can consist of an A and B side, confuses the issue. The problem is whether a spoor is occupied or not. To a timetable planner, spoor B was available unless an operator parked his train there. A train sitting at spoor 7A says nothing about the status of spoor 7B. However, to the planner of the rolling stock, the answer depends on the length of the train at 7A! This problem translates into the question: what is a spoor? Is a spoor an indivisible unit, or is it compound? The structure of the information was not up to it. So, what seemed like a very fundamental unit for a long time, in the end turned out to be everything except that! This only came to light after the various subsystems were created and they were integrated for the benefit of integral planning.

This particular problem remained out of sight for a long time. It had never surfaced before automation, even if employees of both planning departments interacted regularly. The same word had subtly varying meanings in both contexts. However, in direct contact, when talking to each other, language offers humans so many ways to avoid or disambiguate this kind of problem almost without noticing! 

During the nineties, suppliers integrated such programs and offered them as an integral solution. These were supported by enterprise wide data dictionaries. Dictionaries that were mandatory for the entire organisation, giving unequivocal meaning to each entry. For many companies adoption of such Enterprise Resource Programs (ERP) turned out to be a near-death experience. Forcing employees to use standardised terminology turned out to be a dangerous practice. 

When we step back and observe companies interacting, we see that the problem is even bigger. Employees from various companies interact. So the computer programs they use, meet. The same integration problem, only on a larger scale. But this is where the buck stops. There is no entity with the power to force independent companies to use the same conceptual apparatus – that is, to use compatible software.

This is a very big problem, stemming directly from the misconception that meaning and information are two sides of the same coin.

Language and context

Around an automation project, a language forms. A dialect, acquired by the program’s users. At the interface between projects, dialect-speakers meet. Speech confusion is the result. Translation becomes a necessity. Software integration is big business – but a hairy business! Integration problems are the nemesis of many software development projects.

This is no news. IT professionals have been well aware of this issue for decades. Nevertheless, it has persisted, because of the seductive concept of information. Information: the thing that carries meaning, intrinsically. A thought, separate from the speaker, separate from context. What can be the problem, so the IT professional reasons, once we have the right information (design)? And IT makes sure it has an information design. It is the base of each development project. It is the mainstay, the starting point, the coveted asset to be wrestled from the client. It proves to be difficult: users are vague, cannot come up with clear definitions and regularly contradict each other or even themselves.

When the project runs into difficulties, the fault is found in the information model. It is not good enough! We’ll do better, next time.

But they won’t, because there is no shared truth; there cannot be a universal dictionary; information has no intrinsic meaning. A moment’s reflection reveals we all intuitively know this. For example, what is the meaning of the word “yes”? Well, it’s meaning in church, before the altar, is completely different from it’s meaning in the restaurant (where you’d like sugar in your coffee). A cliche? Yes, but very true.

People want to share thoughts and use information – shapes – to convey them. Those who collaborate intensely usually need but half a word. But what is enough in that context, is incomprehensible to outsiders.

We need to learn to think differently about information.

Information should be pushed to the background.

We should put people in the foreground: people trying to inform each other.

We need to accept that the meaning of a shape is entirely determined by context.

Role and Context

Context should be the starting point of automation. Immediately, the question rises: what is a context? How big is a context? Can contexts exist within contexts? How does one automate contexts that are related? What does this all mean for people moving from context to context?

We can find firm ground in the concept “role”. What is a role? Intuitively we know answers, examples. “Father” is a role. So is “Cashier”. “Keeper”, “Opponent”, “Nurse”. Roles form a starting point, because

• we can immediately think of actions expected from a role – very important for the IT professional trying to understand what should be supported;
• roles belong to a context.

A Surgeon belongs in a hospital. A Keeper on the football field. You’re a Father at home. Moreover, roles usually come together with other roles. Mother belongs with Father. Defender and Keeper go together. Nurse and Patient belong with Surgeon. In contrast, Father doesn’t belong with Surgeon, Nurse not with Keeper, etcetera.

In fact, each of us can effortlessly list contexts and roles we play, what is expected of us in that role and what we can do. This is a perfect starting point for IT!

But what is the essence, the definition of a role? Well, it is the actions performed by those who take that role. And, obviously, the question: who gets to play a role? Consider a club, with members. “Member” is a role. The club has a board, with board members. Obviously, only club members can be elected board members. So, roles can fill roles. Or, to be very precise: the board member role can only be filled by someone who also fills the club member role. In daily life we just casually say: “his best friend was his best man”. 

Roles that fill roles – that in turn fill other roles. This way a telescope of roles comes into being. Or think of an onion, layer upon layer. Each layer is associated with data. For example: John has been a board member since 1-1-2018, but club member since 15-9-2000. “To be a member” is not a property that stands alone. It is a property of a role and obtains its meaning in the context of that role. John, in his capacity as board member, “is a member” since 1-1-2018. But as a club member, John “is a member” since 15-9-2000.

The role-telescope provides us with an arbitrarily precise mechanism to store information in the right spot. As an example, consider a company wishing to be able to congratulate its employees with their birthday. “Date of birth” doesn’t really belong to “employee”. Rather, it belongs to the person himself; it is valid in all sorts of contexts and not primarily the context of his job! So really there should not be a place for birth dates of employees in the information infrastructure of a company. The company should not record birth dates, but should be able to access them.

Privacy

A birth date should be stored in a single place and then be accessed by those who need it. Three questions arise:

1. Where to store it?
2. How to find it?
3. Who should have access?

This lands us squarely in the issue of privacy. Who knows what of whom? And above all: who should be allowed to know what, of whom? This is one of the big problems of IT. But I’ve put the matter in terms of IT as I’ve criticised it above. I’ve considered information to be a thing that is stored somewhere, locked up or not. It is precisely the way of thinking that we set out to avoid! Let’s reconsider the issue.

Suppose the cashier in a supermarkt asks you what your weight is. You probably won’t answer that question. It is not an appropriate question for a person in that role! But you would tell it to your GP. 

Now suppose you’re logged into the website of your GP. You would enter your body weight without hesitation, were you invited to do so.  You might even prefer the website to read that fact from some existing information source: it would save you work. Even stronger, you’d find it self-evident that you share such information with your GP and you do not want to give access on a fact-to-fact base. You have a reasonably clear idea of what your GP needs to do his work. Because you are his patient, you agree with him having access to that kind of information.

For similar reasons, you’d deny your supermarket’s website access to the same information! In other words, the information you want to share with someone strongly depends on the role they take and therefore on the context you’ve entered – and the role you play in that context yourself.

The social contract

When one enters a social context, one has a pretty good idea in what roles one will encounter others. And what actions one can expect of them, including questions that will be asked. Conversely, to find oneself in a situation where one doesn’t know these things can be very stressful!

Quite often organisations go to lengths to inform us about the context they’d like us to to enter, as customer or client. What can you expect of us? What do we expect of you?

This is exactly what is required to support such a situation with IT.

We can model such a situation in terms of roles, properties, actions and contexts. It is a model of the ‘contract’ governing the situation. The rules that apply. Participants’ expectations. On entering such a situation for the first time, such a model would be very convenient. In fact, the effort an organisation makes to ease your boarding, might be expressed as such a model (and generating a well written text from such a model would be a breeze, with current language technology).

It turns out we can generate software from it, too.

Utopia

Consider a hypothetical situation. A desirable situation that may not exist right now, but may come into being in the future: a utopia. In that situation models exist, as described above, in terms of contexts, roles, their properties and and actions. Models for all kinds of situations in daily life that could profit from IT support.

On top of that, there would be an IT infrastructure that guarantees the following invariant: a person in a role has access to exactly all information necessary to perform the actions belonging to the role (we consider reading information to be an action, too). Obviously, this infrastructure would use the aforementioned models to determine what the actions and roles are, etc.

In this hypothetical situation,

• there is no privacy problem, by construction. Each role-player has access to exactly the information he needs, no more, no less;
• no information needs to be recorded twice (note that it is hard to make sense of the question, even: ‘recording twice’ presupposes a notion of a place to record, but we haven’t introduced that notion; we did not need it);
• when one enters a context, one can familiarise oneself precisely with what is expected; what roles one can take; what one’s options to act are; and what others will be able to know about oneself. One decides on basis of this complete insight whether to engage in the context or not.
• role-players will be maximally able to attribute the right meaning to information at their disposal. The models guarantee that this is only information needed to perform actions. Actions of a role in a context determine the meaning of the information. It is the meaning of use, the meaning that arises in interaction. 

This keeps the speaker as close as is possible to his message. The source of the message is clear; its destination is bound up in the same context. In this way we have restored communication – in the sense of ‘sharing’ – to its essence. Information will never leave it’s context.

On the usefulness of IT support

What use is IT support? Let’s distinguish between two kind of programs:

1. Programs like a word processor, a spreadsheet, a photo album or a weather simulation.
2. Programs like a flight reservation system, an online market or a dating service.

The first kind of program is used solitarily. The second kind of program supports interaction between multiple users. Such interaction lends itself to analysis in terms of roles and contexts.

What do such programs contribute to interaction?

Interaction between people usually involves communication. Maybe, even, interaction is communication. Whatever: often people talk when acting together; in one way or another, they share thoughts. 

IT can help to bridge a physical distance between interacting partners. A letter, telephone, chat-applications, a flight reservation system: all bridge distance between participants in the same process.

IT also can help to bridge distance in time. A wonderful, simple example is the shopping list, which really is a note to oneself. Standing in the kitchen, one knows what is needed. But once in the supermarket, you may not remember. So it is useful to send your future self a note. One writes down things one wants to read later on. 

Time travel would make IT obsolete. Instead of writing down someone’s birthday wish, we’d just zap back in time to hear him say it again.

To sum up, IT bridges time and distance.

The analysis in terms of roles and actions automatically applies this insight. A fact (a property of a role, for example) would only figure in a model, if there is an action that needs it. So in our example, if the company would actually never use that birth date – if no action using it would be described – it would just not figure in the company model. 

A birth date will be useful, somewhere. But our current IT forces employees to record hundreds of facts that will never be used, because the information model usually is divorced from usage. This will never happen in our hypothetical situation – because it would not be useful.

Perspectives

Perspectives is the name of modelling in terms of contexts, roles, their actions and properties. The Perspective Runtime supplies the infrastructure to turn the utopia sketched above into reality. InPlace is this runtime with a nice looking front end and access to a repository of models. 

Utopia in progress.