Why should quantitative extensions be standardised and automated, and what typically causes them?
In larger companies they happen relatively often, so a repeatable procedure with templates and automation keeps each one cheap and fast; typical causes are mergers and acquisitions, changing B2B models and outsourcing.
Typical triggers:
- Mergers and acquisitions: HR systems are added (an acquired company brings its own HR system) or removed (a sold division takes its HR system with it).
- Changes in B2B cooperation models: a new reseller, supplier or joint venture whose people need access.
- Additional partner data sources through outsourcing: when IT support or logistics is outsourced, the provider's staff need accounts, and their master data lives in the provider's systems.
None of these is a one-off. A group that buys two companies a year, renews partner contracts and outsources services will meet this case many times. If each instance is handled as a fresh project, every one takes months. If it is a standard procedure, each one is a matter of filling in known steps:
- a template data delivery agreement with blanks for the partner-specific parts,
- a standard connector or interface (agreed file format, a standard API such as SCIM, an import job) that only needs configuring,
- automated loading, checking and error reporting.
The quantitative path in the integration flow is therefore drawn short on purpose: find the responsible person, conclude the agreement, connect technically. No data-model or scope debate is needed, because that was settled when the data type first entered the IAM.
Go deeper:
System for Cross-domain Identity Management (Wikipedia) — the standard API that makes connecting yet another identity source or target routine.- RFC 7644: SCIM protocol — the protocol specification behind standardised identity data exchange.