Perspectives on Business

The relation between a big organisation and its IT supplier is a little like diplomacy before the 20th century:

  • the parties live in different worlds and usually have their interests not lined up;
  • they speak different languages;
  • replies take a long time so the process takes forever.

This is fine, up to a point, as long as the parties involved are a match for each other. But things usually get ugly when one party gets too powerful or the other gets too dependent. Tension arises, sometimes leading to outright war.

IT suppliers have always been able to force their way of thinking upon business. Just notice how IT concepts have penetrated organisational and managerial thinking! And how many software contracts have not been based on diagrams and designs that those signing could not really understand?  Let’s face it, running a business is a different game from understanding an IT design.

Problems galore: many projects escape their time- or money box; embracing an enterprise solution can be a near-death experience; many organisations are left with a hangover feeling and software that does a poor job.

This need not be so. On this page we show you how businesses can deal with IT suppliers on their own terms.

Describing business

Let’s assume you’ve taken up a new job, as store supervisor. Sitting with friends, you tell them about what your new role involves. These are some typical actions you would be expected to perform:

  • schedule staff shifts
  • hire new employees
  • draw up budgets
  • check on deliveries

When checking on deliveries, you wouldn’t scrutinise every detail. Instead, you’d be interested in expected delivery time, a report from the work floor on the delivery (is something missing?) and the contact details of the supplier in case something went wrong.
Obviously, for the warehouse manager who actually handles the delivery, knowing in advance what goods (and in what quantities) will delivered, is important to be able to handle them adequately. 
Colleagues of finance are interested in other properties of the delivery. They must know about the cost breakdown and payment deadlines.
So, from their respective roles, each will have a different view of the same delivery.

When hiring staff, an interview committee might be involved. The store chain might have as a rule of best practice that the HR manager always heads that committee. You will be a member. So, in this context, you play a secondary role even if you have end responsibility over the store. The HR manager will have scanned the applicants beforehand. Nevertheless, the decision to hire would be yours. So the roles on the committee are allotted according to positions in the store, and role responsibilities are clearly defined in terms of actions.

Let’s focus on some core concepts (italicised in the above):

  • Role: store supervisor, HR manager, warehouse manager
  • Context: the store, the interview committee
  • View: we’ve seen three, on the delivery: the logistical details, the financial details and the contact details
  • Property: cost, delivery date and time, contact telephone number.
  • Action: check on deliveries, hire staff, etc.

Context and Role

We can draw pictures of contexts and roles to clarify their relationships.

The video shows how to draw a Context Diagram. Two things might jar with your intuitive understanding of contexts and roles:

  • roles filling roles
  • contexts filling roles

Usually we think of people taking up a role. However, in the job description above we actually wrote the HR manager always heads (the job interview) committee. If you look closely, you see two roles. In designing Perspectives, we found it very useful to use that notion. In fact, we speak of a role telescope: roles filling roles filling roles, etc.

What about a Context filling a Role? The job interview committee plays a role in the organisation. There, we’ve actually said it! However, it is a Context in its own right, as it has Roles (the chair, other members, and – oops, we forgot: the interviewee!).

So Contexts are related through Roles. When looking at a Context as it fills a Role, you’ll only see its ‘outside properties’. But when you actually play a role in a Context, you’ll be able to see other Roles, too. And to perform Actions!

Properties and Views

We only allow Roles to have Properties. However, because we have a Role representing a Context (the circle outside), actually Contexts have Properties, too. Let’s draw some Properties on a Role.

In the video, we drew a Role Diagram. Such diagrams just show the Properties on a role and how properties are collected in a View. Above, we referred to the Role telescope. If you draw a Role diagram on a Role that is part of a telescope, you’ll see Properties on Roles higher up in the telescope, too. The meaning of this is that from a Role, you may have access to properties of the Role that fills that Role.


Roles and Views get together in Actions. An Action is easily described in a sentence, such as The warehouse managers changes the ‘complete’ property of the delivery. Here, the warehouse manager is the subject role and the delivery is the object role

Now, in Perspectives, we’d put this just a little differently, bringing in the View available to the warehouse manager: The warehouse manager changes the delivery with the ‘warehouse manager view’. Notice how we used the view’s name as introduced in the video. It is actually not such a good name: in a real setting we’d find the workfloor uses a more adequate name.

We can draw Actions, too.

Collectively, we call the Actions available to a Role, the Perspective of that Role on its Context. We consider consulting some information on the screen to be an Action, too. Actions are part of the context diagram.

From business description to software

It turns out that a description such as we have sketched above, using just two type of diagrams, is actually a complete specification of software. As a matter of fact, we can even (in principle) generate software from it. Of course you need to fill in a lot of detail (such as that the invoice due date property we gave above is a date) and usually there are quite a few Actions to describe. But it doesn’t get much more difficult than what you’ve seen above.

We have given Perspectives a very sound mathematical base. We can translate a model into logic. Models have very desirable properties, such as that Roles, Perspectives, Properties etc. can be incrementally added without compromising what has been modelled before. There is a lot more to the theory of Perspectives than that meets the eye!

All that is very interesting to scientists. But for business purposes, we can stick to a few points of understanding:

  • anyone can understand a Perspectives model of a business or work situation;
  • the model is precise and complete enough to function as a specification for a software building project;
  • with a little training, a business analyst can create such models herself.

This puts the business firmly in the driver’s seat, when it comes to software projects.

Enterprise Architect

Perspect IT built a plug-in for the program Enterprise Architect (well known among software architects) that supports you in drawing and managing large models. This plug-in allows you to validate your design by generating screens for Actions. These can be composed into more meaningful units by drag and drop.

It is important to understand that these screens are not production-ready software. Rather, they support a validating process. End users generally like to judge ideas more by getting a hands-on feel of what will come, than by reading designs (however understandable these designs may be).

The design process

As there is no gap between the way employees and managers talk about their work and its Perspectives description, analysts find they can actually keep track of a (well moderated) discussion between experts. This means that a model can be created live, as the experts speak.

The process is reminiscent of those ‘brown paper sessions’ that famously promote mutual understanding between co-workers. But Perspectives goes far beyond free-style post-it tacking. Your result is a runnable system prototype and perfect specs for actual system development.

So, in the very same sessions, experts can get a feel for how screens may look and feel (again, please note that it’s generic screens with generic design we’re talking about!).

Just think of how this speeds up the early stages of a digital transformation project!

From design to software

An IT supplier uses a deterministic procedure to derive more traditional specifications from a Perspectives model (such as a UML model, epics and user stories). From there on, it will be business as usual. However, because you’ve given them a formal, precise and complete specification, it will be easy

  • for them to set a price;
  • for you to formally accept the end result.

Moreover, a readily understandable specification will foster understanding of your business with the IT company, too. All too often programmers work on functionality without having a clue of the wider context in which it should function!

Software generation

Perspect IT will complete automatic software generation from a Perspectives model within a year. This process is better described elsewhere (…). The generated software will be fully distributed (meaning users will connect directly to each other, without an intervening server). Companies open to such a form of deployment should be interested in this development!

Please have a look at for an example of an App for citizen end users based on Perspectives.