Modelling fundamentals

I once mentioned, that follow the essential systems modeling (esm) principles. As not everybody necessarily will be aware of what this term is about I feel obliged to explain it here.

The Essential Systems Modeling Methodology was defined and applied by Stephen M. McMenamin and John F. Palmer back in the year 1984. It was published in a book surprisingly called essential systems analysis (McMenamin, S. & Palmer, J., Essential Systems Analysis, Yourdon Press Prentice Hall, Englewood Cliffs, NJ, 1984.).

McMenamin & Palmer use an event-oriented approach to process modelling. Their purpose is to identify the "essential (elementary or atomic) processes" being performed and their relationships to the events that drive the business. According to Steve McMenamin and John Palmer essential systems can be detected by the following gedankenexperiment …

• "If we had perfect implementation technology (e.g., a computer with infinite speed, unlimited memory, transparent interface, no failures, and no cost), which of the requirements would still need to be stated?"
• Every requirement that is still necessary in spite perfect technology is an essential requirement.

The prime purpose of esm is to remove legacy implementation artifacts from the model in order to prevent them from influencing future models. And this ability is exactly my motivation why I want to present this methodology here. In the 1^st attempt of the GenericIAM community to derive a generic process model from existing implemented physical models turned out to be surprisingly difficult; in fact it terribly failed. Or as I stated earlier: In fact it turned out, that especially the most experienced practitioners faced difficulties in getting to the next layer of abstraction.

How to derive the target implementation model in a 4-step Process

McMenamin and Palmer recommend to follow a 4-step specification process:

1. Analysis of the current system
• build a model of the actual implementation of the current system.
• This is the physical system like it is implemented in reality - the current physical system.
2. Analysis of the fundamental concepts of the current system:
• Deriving of the essence out of the current system.
• All implementation specific artifacts are removed in this step.
• Using "perfect technology" as the guiding principle.
• The result is the current essential system.
3. Include new requirements into the essential model:
• Build the new essential model by adding new requirements.
• This model represents all functional requirements.
• Ideally it is still free of any design- and implementation consideration.
• The result is the new essential system.
4. Design the new physical model:
• Build the implementation model of the new system.
• The result is the new physical system.

Finding the essence by this modelling cycle removes implementation artifacts leaving us with the pure functional essence.

The 3rd step in this approach is represents the core of the requirements definition. Here the essential business requirements are documented stating what has to be implemented without defining how it will be done.

This separation enables us to implement the same unchanged essential system using different target technologies. Even when using the same technology maintaining the essential model may turn out to be very helpful. When significant changed are applied to the essential (=functional) model the optimal new physical model may be implemented by a considerably different design that the current physical model.

Avoiding technical "folklore" by assuming "perfect technology"

The assumption of perfect technology leads to the following model characteristics:

• Inside the system there are neither errors nor processing or waiting times.
• No audit-, translation- or transport processes are necessary.
• But the environment of the system is considered as imperfect - as is.
• Along the systems boundary a ring of audit-, translation- and transport processes connects to this real world - the physical ring.

There are more rules, which help us composing the essential systems model, are:

• Essential Processes may be triggered by an external or a time event.
• Fundamental essential processes yield an externally useful result.
• Administrative essential Processes store their results in an essential store to be used by a fundamental essential process.
• Essential Processes communicate asynchronously via essential stores - they are time decoupled.
• Essential processes may be expanded to form nested essential models on a lower layer; essential models in turn may be collapsed to serve as essential processes on a higher level.
• At the lowest level the essential processes represent elementary activities.
• The elementary activities can be found by discovering state transitions of the fundamental (persistent) business objects.
• Elementary activities typically bundle all actions, which are done by one processor without a necessary interruption.

In order to form business processes elementary activities are grouped by their inherent business relationship.

The business relationship is expressed in the value chain and can be taken from there.

Business processes behave like travelling guests

• they are created by an event,
• they are themselves transient objects.
• they undergo several state transitions.
• they change their state by elementary activities.
• they carry along their local knowledge about triggering events, acting processor, affected business objects.
• after delivery they terminate their active life by may be archived.

Equipped with this methodology and keeping these rules in mind in my next post I try to do my first cautious steps to derive essential IAM processes - which hopefully will turn out to be truly generic.

objects, subjects & actions

As from a purely static picture we will never be able to derive the dynamics, i.e. processes, clearly time has come for some dynamic considerations.

Remembering the RBAC definition of permissions as ‘actions on objects’ we are clearly still missing that someone who performs these actions, the actors. Hence these special objects, which are able to act, turn into subjects:

In processes subjects (actors) act on objects.

Subjects may be users or managers

Managers are owners or clerks.

• Owners are responsible
• Clerks act on behalf of owners
• Owners delegate to clerks

Subjects act or react

• Their activity triggers an event
• Reactions often are decisions (like approvals)

What now is the difference between acting and reacting? Does any subject really act on its own discretion?

Keeping in mind that we only regard events triggered by subjects which are confined in the IAM system any action which are triggered by external events can be regarded as actions.

Follow-up actions whose events were triggered by preceding actions can be regarded as re-actions.

Time may act as a (virtual) subject

• Time acts on behalf of the organization
• Time triggers a predefined action
• The action is driven by a policy
• Time-triggered events are common

events

I mentioned the term ‘event’. Events trigger the dynamic, the make the system move.

• actions (and whole processes) are triggered by events.
• There are events …
• fired by embedding business processes.
• created by an subject
• triggered by time
• fired by state transitions

Events from outside the IAM system we call business events. Without business events there would be no need for the entire IAM system.

Request & approval

Let’s have a closer look to the action itself. What happens when an individual applies for access to an object? It requests access. In an abstract view a subject requests an object. As done before we can derive an object from this relationship: the ‘request’.

• The request is a transient object but it may well be persisted.
• It is the central workflow object found in IAM systems.
• It can be understood as the instantiation of a process type.
• The request is created by an event, e.g. …
• when a subject requests access to an object.
• when time has come to re-validate a role / privilege.
• when the defined response period has been passed without an activity (escalation)
• …

Who now approves a request? As a general rule the owner of the requested object has to decide whether to approve or to deny.

• The objects’ owner decides on the request
• Hereby he changes its state
• States are:
• new
• approved
• rejected
• escalated
• We can expect as many requests as there are object owners.

To make the situation even more complicated - objects owner may delegate the decision to someone else or activate a policy which acts on behalf of him following pre-defined rules.

Subjects decide on requests

Let’s summarize:

• In workflows subjects (actors) act on objects
• The acting subjects may be owners or a clerk
• Owners are responsible
• Clerks act on behalf of owners
• Owners delegate to clerks
• Owners may pre-define their decisions by activating policies.
• Subjects act or react
• Their activity triggers an event
• Reactions often are approvals

 

Every object has an owner

The guiding key concept is the concept of ownership, assigning the responsibility for an object to its owner:

• Each object as one owner
• The owner is responsible for the object
• The owner may delegate object management to a custodian.
• The owner may temporarily transfer ownership (full responsibility) to delegate.
• Owners differ considerably from one organization to another
• This apparent complexity is a result of customizing a simple model

In my next post I should try to identify elementary action which we later may use to compose IAM processes.

But before doing that I like to insert a few words on the modelling approach we use here: the ‘essential systems modeling’.

It therefore may be worth to stay tuned.