Congratulations! Your company just completed a merger. Shareholders are happy, but those responsible for the new organization’s information technology are terrified.
After all, information technology has become a key enabler of the business, and in order to truly become one business, everybody in the newly merged organization needs to use the same tools, applications, and data. And so all eyes are now on the IT staff to figure out how to make that magic happen.
Infrastructure is the easy part, but until you tame your identity data, you can’t empower the organization with the same applications. More changes to the identity data result in more risk, and the clock is ticking. That risk has been known to lead to analysis paralysis, with some large organizations maintaining distinct IDs for years after a merger. Leadership, not to mention shareholders, are watching closely to see progress. How will you move the organization forward?
Formulating The Right Strategy
- Where will your applications and infrastructure consume identity data from?
- How will that data be created in the new identity data service?
- How will that data be managed, going forward, to make sure that it remains “evergreen”?
Given that the integrity of the enterprise data is to be protected above all, it’s understood that the processes that create your identity data will be reviewed and revised. Sources are changing. Processes are changing.
And now where you previously had only a few identity sources, you may have five primary identity sources, between two organizations. Two distinct Active Directories, two LDAP directories, and an RDBMS. All of which are managed via disconnected processes, as they’re managing islands of data.
But, islands of data are difficult to consume.
Enter Abstraction Based Identity Service
An abstracted identity service can read the information from any desired source and present a view of that data to suit your needs. Information from all sources can then be exposed in a virtual namespace, where we can provide as much information as is necessary, say for efficient consumption by a web access management solution, or a highly restricted view that exposes only minimal information, without needing further access control instructions, because the data simply isn’t there.
That object passes authentication events back to the original source, as configured, reducing password synchronization problems. And all of the authorization information off of the identity that was joined from all five locations can now be available in one place. Meaning that, depending on your use case, you can point your applications to a single source of information, allowing login from either company, with consistent authorization data.
And the pièce de résistance? The aggregation of all of your identity data together streamlines the business integration (because the identity data is typically the hard part.) So, once you get the identity data together, you can migrate to the same set of applications. It’s hard enough to become one company culturally, but when each legacy organization has to use separate applications and processes, it becomes nearly impossible.
Tactical Value, Strategic Relevance
The architectural principle of identity abstraction not only streamlines user experience, but it allows for potentially significant streamlining of post-merger integration. And if there were another merger down the road, you don’t even have to change the applications. Just add the source in the blue layer above, and enjoy the beaming grin on the face of your CIO.
In one fell swoop you’ve addressed the tactical problems related to the merger, established an architectural direction to empower agility, and provided the framework to absorb the next acquisition in record time.