Enterprise Modeling: Two Perspectives

If you want a car to operate more fuel efficient, there are several ways to achieve this: you can avoid abrupt acceleration or deceleration (breaking), turn the engine off when you come to a stop, or plan your route to avoid congestion. These are all examples of changing how you use the car. Other things you can do to make it operate more efficiently are: adding air to the tires – not too much! -, shedding weight by removing unnecessary luggage or persons, or opening the bonnet in order to optimize the engine. In all these cases, you change the actual car and not just how you use it.

In system modeling we can discern two main perspectives: the function perspective and the construction perspective. The function perspective conerns what it does; the externally visible behavior of the system. It is a subjective view, related to the person or sakeholder group that looks at the system. The construction perspective is about how the system delivers or realizes the (designed) function. It is an objective view, that does not depend on who is looking to the system, and describes the structure of the system in terms of its components. In the example of the car, the (main) function is to drive or be a means of transport from A to B. The construction of the car is composed of the chassis, the wheels, the engine, the steering wheel, the lights, the pedals, etc.

In order to change the function of a system, you have to change its construction.

A function can sometimes be changed or optimized by using it in a different way. You could even assign new functions to the same construction: for example, you could sleep in a car, even though it was not designed for it. However, if you really want to change or optimize a function or quality aspect of a system, you have to change its construction.

For software, as another example of a system, the same perspectives apply: the function of the software is usually expressed in (user) requirements or user stories. The construction of software exists of computer code, usually organized in classes, variables and methods. This distinction mainly coincides with the (two) distinct roles of business analyst/product owner versus software developer.

Function and Construction of Enterprises

For enterprises, this distinction in roles is far from obvious. Most business analysts and enterprise models focus on the function of the enterprise, such as with BPMN, ARIS/EPC, and Archimate. A possible reason is that most enterprise and process modeling languages only include a representation (syntax), but lack meaning (semantics) of those constructs. The functional perspective is often considered enough to `manage’ the enterprise by looking at (KPI) reports.

However, if you conclude that the enterprise needs to be changed or improved in order to operate more efficiently, you need to look at its construction. DEMO clarifies that the construction of an enterprise consists of human beings that enter into and comply with commitments. The human beings involved can have the role of employee, customer and/or supplier. Human beings can be abstracted to (actor) roles and commitments to transaction kinds, that need to be implemented with some technology, such as human beings and IT.

The construction of an enterprise is a key deliverable for software development

This view clarifies that if you want to change (the function of) an enterprise, you have to change the actor roles and transaction kinds and/or its implementation with human beings and IT. Another implication of this view is that software is part of (the construction of) the enterprise. As a result, requirements for software can only be logically deduced from the construction of the enterprise, making the construction perspective of enterprises a key deliverable for software development.

Want to know more?

On the DEMO website you can find (introductions into) the DEMO way of thinking and modeling, in both English and Dutch.