essential IM processes

If we restrict our considerations to essential processes (see Modelling fundamentals) there are mainly the identity maintenance processes to be taken into account. Only when we (later) extend our view to the physical implementation processes like provisioning, reconfirmation (re-certification), format transformation, reconciliation among different data storages and the like come into play.

The first and most fundamental object to be considered of course it the digital identity or just identity. Under the assumption, that the organisation and an individual's contract relationship with the organisation is modelled elsewhere (outside of the IM and the AM) just the functional role (business role) and the constraint are left to be taken into account.

There is probably not much left to be said about the digital identity as I devoted an own BLOG post to it here (http://genericiam.blogspot.com/2010/06/identity.html) nearly one year ago.

But what's about the business role? I also called it - perhaps more straightforward - the functional role. It just expresses the functions out of the functional (static) business model which are bundled in the functional role. I will probably dedicate one future post to the way how to find functional roles.

And there is the strange remaining object, called constraint. What's that? In this object we collect all additional constraining and determining information like authorisation limits, organisational unit (OU), region, contract type (fixed term employee, interim manager, contractor, …) or the like. This information is certainly necessary. Only if it is wise to stuff them all into one object and calling it constraint is left to the modeller's discretion to decide. For now and for the sake of simplicity I will not split it off into its probable components but leave it untouched.

How to derive processes now? Well, obviously we need some maintenance processes, the CRUD processes (create, read, update & delete). But it all starts with an event. Otherwise there will never be a need to start a process.

For the creation the triggering event is the very moment when an individual starts a relationship with the organisation. So whenever an individual enters the enterprise ecosystem 1^st time its digital identity is created.

This should be done regardless if it is a user or not as being a user represents a class of roles already. 

As an example the activity employee.create is among the 1^st steps of an on-boarding process within HR. The equivalent is true for CRM, PRM & IAM.

The digital identity hereby is the individual's digital sibling. Its lifetime is determined by the lifetime of the enterprises interest in it and / or by legal or regulatory requirements.

The digital identity is global and unique within the enterprise ecosystem during its life span - or the identities' space-time-continuum, if you prefer science fiction slang. It just carries the minimal necessary set of identifying attributes.

So 3 fundamental business process groups remain for now which are tied to the digital identity:

• on-boarding,
• off-boarding &
• change processes

They are split of by the type of the digital identity.

These processes differ slightly by the type of digital identity to reflect the difference of the underlying relationship between the organisation and the individual.

How to find IAM processes

Just recently I made an eye opening experience. While delivering experts advice to a customer in a large IAM project I was asked if I could confirm that the set of IAM process descriptions that was delivered by a colleague of mine was correct, complete and compelling.
Hmm, my colleague is an experienced practitioner. He did this job several times before. He knew what he did. I trust his expertise. So I asked him how he derived them.
"Well I just know that you need these processes. And taking into account the special situation at this customer's site this is the most reasonable result" he argued.
"But they couldn't have appeared from nowhere. There must be a convincing and compelling way to rigorously derive them from the situation we are in" my customer replied.
This was déjà vu. Here it was again - the demand for a generic set of processes for the Identity- & Access Management. So I felt we finally should come up with an answer. And I tried. It goes like that "
First step is getting some order into the seemingly unlimited number of possible IAM processes by grouping them. The Processes of the Identity Management " not surprisingly - may be grouped in several ways. Her I propose the following sequence:

1. into Identity Management & Access Management
2. into operational and managerial processes
3. into essential and physical processes

1. Separating Identity Management from Access Management

Identity management has a justification sui generis. It needs not to be regarded as an appendix of security management or just the precondition for Access Management.
Access management - of course - can be and should be built on top of Identity management.
The key question however is where to draw the line between IM and AM.
The digital identity, i.e. the object "identity" clearly is in scope of IM. Out of scope of IM and of AM on the other hand are the objects "organisation", "contract type" and "contract". They should be modelled elsewhere in the enterprise model.
But what's about the business role? It defines the functions an identity is meant to perform in relation to the organisation.  And defining the relationship should be still considered as a part of the IM. To my opinion it is more safely located in the IM than in the AM.

2. Subdividing into operational and managerial processes

• 1^st rule: keep processes short: "the best way to manage workflow is to avoid it"
• Operational processes tend to follow this rule.
• However in the back office they tend to grow ever longer.
• Regulation, compliance issues and security concerns are the drivers.
• There are just a few operational AM processes: identify, authenticate and authorise
• IM processes are purely managerial by their nature.
• There will hardly be any strategic IAM processes found ever.
• The bulk of the processes are managerial by their very nature.

3. Order by essential and physical processes

Follow the rule: essential system 1^st − physical ring 2^nd. Meaning you start with the stable essential core of processes. And only if this set is complete, they are followed by the more volatile physical ring.

Hereby essential processes …

• represent the business' intended behaviour.
• They can be identified assuming "perfect technology"
• They need not to care for transport, translation or audit activities.
• They are implementation independent.
• They form a durable core of the business.
• They only change if business changes
• example: administer and use the essential business functionality

Whereas physical processes …

• are introduced to deal with the imperfect outside world.
• Here transport, translation & audit processes are introduced.
• Physical processes are implementation dependent.
• They are more volatile and subject to frequent change.
• When re-implemented the physical ring will be different while the essential core may stay unchanged.
• example: integrate, transport, transform and "provision" to deal with the "cruel dirty world" outside.

In my next post I will follow my own recipe by applying it to the Identity Management (IM) first. This should be the easy part - with harder parts to come.

Objects of the corporation - slightly revised

Looking back to the Objects of the corporation, which I defined back in 2010-07-05, I felt the need for some minor adaptations in order to comfortably derive the elementary actions for its manipulation from this model.

IAM-objects & non-IAM-objects

Everything starts with an agreement …

We only care about the digital identity in the corporate context if it maintains any kind of relationship with the organization or an organizational unit (OU).

Let’s state therefore: the identity has closed a contract with the organization, not necessarily a legally binding agreement; whereas usually it is. Although not in focus of the Identity Management the digital identity’s lifespan within the corporation starts with an agreement. There may be more than one of them like a freelancer contract and a bank account creating a customer-supplier relationship or an employment contract and the membership in the workers council.

To take full advantage of the possibilities to automate role assignment we could later resolve the fine structure of the object organization. For now however it may be sufficient to deal with a monolithic object.

Contracting is usually done according to a standard contract type covering at least one standard position, e.g. sales representative of securities trader. Each of these standard job descriptions covers at least one functional role.

The functional role just specifies functions to be performed. What still is missing is the information object to be accessed. Therefore the business role needs to be localized by further constraints in order to bind it to specific permissions. The result is stored in the business role. There are of course many more business roles than functional roles, accessing different incarnations of the same information object type.

According to the RBAC definition permission is an operation on an (information) object.

… and ends up in an "authorization".

The identity’s access to an information object - expressing the use of the object - is stored in the authorization object. There may be one or more authorization object per identity.

Constraints may be specified in the same agreement as the function or in additional agreements and applied to the business role. For example the amount of money, a bank clerk is allowed to sign a credit contract for, may be limited. Or the authority to purchase material may be limited to a specific organizational unit.