Skip to Content
Author's profile photo Paul Rostagno

In search of the critical mass

Dear reader,

In this article I would like to discuss how to engage in an IDM project. We saw last time that IDM could be used not only as an employee profile management system (generally sourced from an HR platform) but as well to maintain and provision external users (generally sourced from company-controlled external Web sites). In fact, it could even be used to maintain various other types of objects, but we will examine this another time.

The critical mass

The challenge with this type of Enterprise program is to find a business owner that will support and sponsor the project. Indeed, your Identity Management system may eventually serve many lines of business that would need to share the investment cost. IDM comes with many adaptors to various systems and the group who is best positioned to grasp the overall future benefits of such a program is generally the IT Department. They need to make the landscape work. Interconnecting systems to make it work is primarily a technical problem, rather than a pure business problem. While reviewing and prioritizing the company road map, the business stakeholders will systematically ask “what’s in it for me?”, which is a fair interrogation. The Agile Approach fits well with an IDM implementation. Indeed, there is simply too much to tackle to go with a big-bang waterfall approach, so that tailoring stories per business use case is a pertinent methodology.

Proposal for a high-level methodology

Since there is no such thing yet to my knowledge as an Identity Management framework for the business approach, I will attempt at drafting one here, based on our internal experience at SAP Global IT. Experts could probably write a book on such a topic, and a blog may not be the best format to address the question, so I will necessarily limit my comments to a bird’s eye view here, providing general insights based on my experience. I apologize if this may frustrate people in search for a chiseled planning and detailed step-by-step operation mode. Of course, each company is free to put variations to it – or rewrite it entirely – that would make it more palatable to their own industry or business case.

Three main use cases will be addressed by your solution:

  • HR integration for new hires and life-cycle management
  • Master Data integration across the enterprise landscape
  • Security requirements

The first and obvious business requirement will naturally come from the need to replicate HR profiles to downstream applications and control their life-cycle. When an employee joins the company, she will require immediate access to various business systems such as a CRM or an ERD, with permissions adapted to her job title, Department or combination of both. For this, a role should be drafted at design time and then automatically granted at run time.

Global Risk and Compliance features may quickly surface as a derivative of this first need, in order for the company to pass the more and more exigent financial audits. Here we will strive to bundle IDM with a GRC module such as the Business Objects one.

An IDM architect should become the best cross-applications generalist. Hunting for pockets of redundant master data across the landscape should be part of his or her responsibility. It may be that most internal applications already gravitate around a user repository such as a corporate Active Directory or an LDAP registry, while a few others have been built in silo. The bigger the company, the more probable it is to find such examples. Reasons may be that the general repository technology is not available for a particular application. Such application may use a SQL Server database, while such other one may use an Oracle database to store their profiles etc. While the preferred choice is to gather all applications around the most relevant technology, it may not be an option for some persistent exceptions. It may even be that certain attributes can be updated from a different entry-point than HR. As an example, an employee’s photograph may be updatable in self-service via a Corporate Portal front-end, or an enterprise Address Book, and this new photograph should then be made available via an Expert Finder application, or should be seen on a blog portal. For all these cases, a central hub is necessary to avoid data discrepancy (former value still present in some applications while the updated value can be seen elsewhere). IDM will ensure a technology-agnostic propagation of profile updates to all applications.

To be clear for readers not familiar with the SAP Netweaver IDM as this is not obvious, this product’s reach is not limited to SAP technology connectors but can and should be used for all connection points whatever the technology: LDAP, SQL Server, Oracle, Sybase, REST APIs, Web Services, jdbc, you name it! If you find a technology where an out-of-the-box connector doesn’t exist, you can even build a client in Java for example and call it from the IDM internal provisioning system.

A collection of business use cases should be gathered by the architect, and used to argument in favor of a new Enterprise Architecture framework. These use cases will eventually translate into epics and stories depending on their size (a story would typically require 2 or 3 days to complete). The development team will then commonly agree on the list of granular tasks to execute in order to deliver on the stories.

More granular Use Cases may be defined along the following lines:

  • Propagate HR new employee profiles to a company Address Book or Employee Directory,
  • Provision HR employee profile creations to a CRM application, or an ERD application
  • Disable an employee profile in all corporate applications after an employee leaves the company
  • Provision an employee role assignment to a downstream application
  • Provision an external user profile creation, update or deletion to a reporting system e.g. Hana
  • Replicate external user profile updates to various Web properties such as an online store
  • Etc.

The more you encompass systems within the scope of your implementation, and shed some light on shadowed or neglected areas of the enterprise landscape, the easier it will be for the business to take ownership of your initial IT proposal and back it with their strong financial and steering guidance.

A strong determination, analytics and persuasion skills are qualities that are well sought after in this adventure…

Eventually, your system will reach the critical mass, in which the initial cost of the program starts outweighing the financial benefits. This critical mass can be calculated as follows:

Cost with IDM as the center of a start model:

  • Estimate the cost of the systems setup: DEV, QA, Production: this should include both servers (physical or virtual) and software (SAP Netweaver IDM, SQL Server) as well as ramp-up time (e.g. 50 PD x number of developers) for the development team to learn and become highly efficient with the new technology;
  • Estimate the integration costs: interface between HR and your new system, between your system and any downstream system you can foresee. This is your resources cost that you may want to gage with your traditional PM measuring stick, e.g. 50-100 PD per interface including development, unit testing, PM, QA phase and deployment depending on your IT local challenges and technology.

Cost without IDM (“chaos model”), with redundant integration points:

  • Here the integration costs will represent point to point interfaces between your systems, e.g. HR to CRM, HR to ERP, HR to Corporate Portal, Corporate Portal to Active Directory, Corporate Portal to External Web Site etc. Quicker than you think, you will come to regret the lack of structure of such architecture.

Your ROI demonstration to the business will derive from the calculation of the critical mass in terms of number of systems gravitating around your Identity Management hub. At some point, the benefit of building a clean star-like architecture with single branches connecting each satellite system to the IDM center will become financially obvious.

Indeed, for each added system in a star-like architecture, you only need to build one branch-like interface, between the new satellite system and the IDM center, while in a chaos-like architecture you may need to build several interfaces out of any single new system, especially if this new system is an entry point for master data updates: connection to CRM, connection to HR, connection to Address Book, etc.

At this time, your initial architectural choices will have covered the initial investment of building an IDM landscape and ramping up your development team, and the margin will start fueling your enterprise landscape growth engine: instead of building 2 or 3 interfaces right away for your new marginal system, you will only need 1 interface to IDM and control the flow of attributes and rows per target system directly from the IDM Identity Center. You will do the math: 2 or 3 times the 50-100 PD versus just one time 50-100 PD.

At this point the business will be won to your architecture choice!

The Security requirements will only consolidate your motivations for a new IDM architecture: your company may be subject to audits during which you want to demonstrate who has access to which system and with which privilege. The business rules that you will develop in your new IDM system will save you of sleepless nights trying to identify loopholes in your security model.

The endurance run of the IDM architect

As we can see from the above, Identity Management is an Enterprise Architecture topic, resulting in structural changes across the landscape.

While an Agile approach is tailored to provide immediate benefit right from iteration 1, it may take quite a few iterations to build the critical mass described above.

Before reaching the critical mass, your program will be labeled as an “IT project”, with all the pejorative connotation that traditionally comes with it. You will have to fight searching for business support for your project in these early days. Your struggle will be exacerbated by the fact that you will serve several lines of business at once, with no central owner. This is why this type of approach must come from the top, namely the CIO. Only the CIO can give the initial impulse that will help you make the right architectural choices when business stakeholders may remain lukewarm. After the critical mass has been reached,
business owners will come from all directions to claim full ownership of the new engine, reaping the rewards of the initial choice. At this time you will know that you won the battle, for the sake of the company.

I hope you will find some take-away price in this series of shared experiences on the Identity Management topic. Or maybe you will be amused by the discovery and contemplation of the wanderings and challenges of the job. Next time, we may talk about the security model and “entry types”. As always, your feedback is most welcome!

Kind regards,


Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.