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 1st 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 1st 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:
These processes differ slightly by the type of digital identity to reflect the difference of the underlying relationship between the organisation and the individual.
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 1st 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 1st 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
My friend mentioned to me your blog, so I thought I’d read it for myself. Very interesting insights, will be back for more!
ReplyDeletedigital identity