Project Scope and Sustainability

(This post was written by Matt Pollicove)

One thing I’ve noticed when talking to people about Identity Management projects involves how to determine the project’s overall scope.  “How do I scope this?” they will say to me.  Now that’s kind of tough to answer right off the cuff, especially when considering Pollicove’s Law of Provisioning  which basically says there’s no guarantee that companies that are in the same vertical will work the same way.


However, I think there are some best practices that can be worked with when considering implementing an Identity Management solution:


1.       Make sure you have executive sponsorship.  C-level support is going to be important in balancing the needs of your stakeholders and their budget dollars.

2.       Make sure you have a good plan of what you want your Identity Management solution to cover.   An essential part of this is conducting a thorough assessment.  Document everything, diagram existing processes, then take them apart and put them back together the way they should be, then do it again.  This should be done with a combination of internal and external sources.  Internal resources know how current systems are configured and interact.  External resources will offer an impartial assessment of how these systems can interact more efficiently. External resources will also be helpful in determining which Identity Management products will work best in your infrastructure.

3.       When building your plan, know where you’re starting from.  What will be used as your authoritative store?  How will it be built?

4.       Where are you going to? What will you provision to?  What will you control access to?

5.       How are you going from 2 to 3?  How will you engineer your changes?  What will the phases of your project consist of?


Item 4 is probably the most important part of the process.  Many a project has suffered due to overreaching phase objectives. Carefully define what you want to achieve in each phase. 


Data cleansing and analysis is almost always your first phase.  If you don’t have clean data, you won’t have a clean project.  Future phases can deal with:

·         Creating an Authoritative Store

·         Provisioning to essential systems

·         Password management

·         Role management

·         Provisioning to secondary systems

·         Etc.


So the big question is what order does this happen in?  How long will it take?  I always suggest attacking “low hanging fruit” first by attacking the easiest objectives that will show the biggest net gain?  As a part of number 1 above, think about solving automation needs, compliance needs, addressing password management request costs to the helpdesk? 


How long will it take?  As long as it has to.  This is going to be a major project that will affect many systems and departments.  Take it slow and easy.  Test it thoroughly and make sure there’s a good knowledge management/training initiative to let your users know what happening and how everyone will benefit.  It’s never good if your users equate an Identity Management initiative with a foul tasting medicine.  This includes your stakeholders.

More Thoughts on Federated Provisioning

If we look up the definition of the term “federated” in the Computer Desktop Encyclopedia via it returns this definition:

“Connected and treated as one. See federated database and federated directories.”

This definition makes sense when we discuss identity.  We have two systems within separate legal entities separated by a barrier.  At one time this barrier was  like a wall, a fortress.  Entry was made through prescribed gates.  Today it is more like a cell with it’s bi-layer lipid membrane and  trans-membrane proteins.  It acts as a protective barrier and a regulator of transports in and out.  When we connect the IdM system of one entity with another they are treated as one; however, the other sub-system elements are logically subordinate so if we talk about federated provisioning there is a strong argument that it is semantically irrelevant.  Ian Glazer is right there is only provisioning.

Federated Provisioning & SPML

I enjoyed this post over at the Burton group.  He makes the point that we should only have to concern ourselves with provisioning to an application not federated provisioning and I concur.  He also bemoans the fact that many applications and SaaS  applications  lack a SPML interface.  In the comments one “Dr Joe in NH”  stated the following:

SPML is terrible spaghetti at best. Having worked for a SaaS org, we looked at it and decided it was overkill for something that could be done in a much more compact and simple fashion.”

Amen and that could apply to nearly every WS-*.  All  are based on XML the extensible mark-up language which isn’t extensible and isn’t a markup language.  XML turns everything into an artificial hierarchy which is in a word,  medieval.

Netweaver Identity Manager 7.1

Now that Netweaver Identity Manager 7.1 is in ramp up, the single biggest change is at the presentation layer.  PHP is gone and Webdynpro is in.  The inexorable march away from its open source foundation is well under way.  When we first started showing the product to customers they would inevitably say, “This doesn’t look like an SAP product” and they were right.  This lack of familiarity made companies hesitant to purchase the product.  The same thing happened with master data management.  The other issue was PHP.  In meetings with infosec managers, they would make comments like, “PHP is not a core competency here.  We don’t have anyone familiar with PHP.”    Normally, I found out this wasn’t true, it’s just that the developers who knew PHP well were doing projects with it for friends and small businesses.  Long term this change is positive.  The better the product integrates with SAP, the more satisfied the enterprise will be and they can leverage existing competencies.

Desperation Selling

With economy turning down and companies prudently freezing or cutting budgets the season of desperation selling will be under way.  Invariabley large companies with access to capital will see this as a time to lower prevailing rates on consulting.  Small thinly capitalized consultancies trying to survive will be more than happy to low ball bids.  Having worked in many start ups and also in large enterprises I have been on both sides of the table.  What this experience has taught me is that once you drop your rates, when the economy turns customers who gave you business will strongly resist higher rates and in some cases act betrayed when you attempt to charge the prevailing rate.  I learned that you have to say no to the grinding on price.  When the negotiation gets down to just price it turns into a street fight.  As a consultant they are buying your knowledge, do you really want to dilute the worth of what you know just to get the business?  I learned to say no and pass on the business beyond a reasonable discount.  Either the value is there or it isn’t.  Regardless of the price you accept work for , the expectation for performance remains the same.  They can be happy with your work at x or 2x but you may be miserable at x.