Note: This is an out-of-context excerpt from work I am doing elsewhere.
This page is two of a series of three:
- IdEAs Business Architecture – Capabilities
- IdEAs – Production Model for Digital Identity
- IdEAs – Identity Information Management
Digital identity services are no different from any other in that once you have identified your business objects, you have to organise resources to produce them.
By far the most common strategy is to acquire commercial software built to implement those production capabilities and then to slot that into your existing management and service production systems.
That is an approach that is often quite good for small to medium sized organisations.
If your organisation’s identity domain is characterised by one or more of,
- highly diverse constituents,
- high mobility of constituents within the domain,
- high volumes of affiliation and disaffiliation events,
then it is likely that a buy and install strategy will be ineffective.
Large complex organisations should consider digital identity services as an essential platform requirement for a range of important use-cases (not just access control).
This requires a sound understanding, and articulation of an operational architecture for the production and operation of digital identity services.
Smaller organisations can still benefit greatly from an understanding of digital identity services as a production problem without reference to the idiosyncrasies of a specific product.
Four capabilities (or functions) are required to produce digital identity services.
Each function may be described using a common production model. The model describes the business and operational architecture of each function.
The production perspective is intentionally abstracted from considerations of technology, data architecture, and related technical services.
The following generic concepts are used to describe production:
These are those behaviours of the function that are produced with the intention of being visible and useable to other parts of the organisation. The mode of each service (end-user, business, application, etc.,) is not described. A service may be produced directly by a function, or be produced as the result of a function collaborating in a cross-functional process.
The intentions of a function are described in terms of discrete and structured activities for which objectives and metrics may be defined and to which skills, tools, and knowledge may be allocated.
The structured and formally defined behaviour through which the function will carry out its activities and produce its services. Process may realise activities solely within a function, or collaborations.
The business objects are the conceptual objects the function is responsible for producing and managing. A business object may be a static informational entity such as an identity or an entitlement, or it could be a dynamic entity such as authentication or authorisation transactions.
A collaboration is an activity that orchestrates the production resources of more than one function to produce services.
The (draft) reference architecture presented here is not controversial and most IT production systems will look something like it.
It is derived from a number of sources including NIST, The Cloud Security Alliance, and Gartner.
The following diagram represent the generalised producti0n model in mongrelised pseudo-Archimate.
Here is an outline of how this model might be applied to the Identity Information Management function.