Once you've done your research (or its been done for you) and the software license purchased, we all know what the next question will be... How will this software get implemented and how much will it cost.

Beware of boiling the ocean IdM projects (check out the "boil the ocean" analysis for Solaris 10's ZFS) IdM Projects. As mentioned before, IdM can address several different areas within the organization, including:

1. Provisioning/reduced system administration
2. Compliance Implementation
   
3. Compliance reporting
4. Compliance auditing
5. User Self Service
6. Password Resets
7. "Meta" directory functions
8. Reduced support tracking
9. Authentication and Authorization
10. Centralized directory consolidation

So, what to tackle and what will it cost?

The last article warned of getting trapped in the compliance death spiral. Helps you get started, but your budget could end up on the cutting block.

Can't tell you how many large clients try and go after a big project and have unrealistic expectations of what it costs to implement these projects (see our ROI calculations before to help justify the costs).  But we continually run into clients trying to IdM for $100K or less.

Any of the analysts within the space will tell you this is an ongoing ERP type  project. There is no end, just evolution. So be realistic to your upper management. It will cost six figures, and possibly seven (oh, no, Mr. Bill!) and it may be a while before savings recover outlays.

At a recent client, where we reviewed their attempt at implementation and consuled them the amount targeted for the type of installation they were trying were unrealistic.  Well, a new CIO has come on board (gee, what happened to the last one; he was cutting costs!), who actually worked for a competitor of ours. He looked at the budget and claimed that it was way underfunded and needs a review to recalibrate expectations and costs.

Look, we are not in the business to drive up professional services as much as we can (and to the disbelief of some).  But be realistic, this is a complex topic that will affect your business and will save money in the end.  As we tell many clients, this is brain surgery. You will be messing with the core directory and authentication mechanisms that run your companies systems. One slip of the knife, and you can serious maim or kill the patient. Permanently. 

So, how many people have the expectation that brain surgeons should be shopped around for the lowest cost?

As we have mentioned before, Identity projects, particularly provisioning, are not your normal IT projects. They will test your skills as a project manager as you have to negotiate the corporate waters of not only IT, but Finance, Complaince, Security, HR, etc.  You will have to build consensus with all of these groups you normally don't have to get in close with if you are going to be successful.

So let me relate one place where your project can get put where you may be stuck in a funding death spiral. Watch for it and be prepared to build your case to get out of it.

In many organizations, IdM is first put in place to help with SOX compliance.  Good thing at the start; has to get done, major penalties if your company doesn't comply.  Budgeting is easy to justify. Get IdM in to solve the compliance issue and we will circle back later to do all the cool, positive ROI stuff like user self service, etc.

The problem with making IdM a compliance project out the door is you have to watch where your budget is coming from.  If your project will last a while and into the next budget cycle, you run the risk of having your project classified as a compliance project when it comes time  to carve up the upcoming budget dollars.

And you are now at the event horizon for the black hole your project may get sucked into, never to return.  By being classified as a compliance project, it will be looked at by senior management as overhead and a non-revenue generating activity.  Some of my clients have even had the CTO flip the project over to the Chief Compliance Officer, trying to get this "compliance anchor" off his budget.

And as a compliance activity, management will start to strangle available funds for building on the IdM platform.  Even if your CTO suddenly gets the "ah-hah" moment on what an asset the IdM platform is to his organization, it may be too late; he or she no longer handles the purse strings, the compliance officer does. And their goal (being from a financial background for the most part) is to get things done for as little capital expenditure as possible.  The project will be installed, monitored for compliance, and funding will dry up.

So be aware of this IdM funding death spiral. Start out as a compliance project, but be sure to keep selling the ROI benefits for non-compliance extensions to the platform.  Keep your project in the graces of those you will need in the future to help fund your vision.

And as a final note: want to welcome another Sun IdM blogger: Mike Wyatt.  He is the head of our AES team within the software practice. Thats Architecture and Enablement Services - we help figure out how to implement IdM software with our client. His blog will also deal with Identity Management projects, focusing on where they can fail. I am sure you will enjoy his insight and knowledge from years of working these projects at major clients. Mike is one of the jewels among many we acquired when we picked up Waveset. Welcome Mike, happy blogging.  Also be sure to check out Mark Dixon and Sara Gates for more IdM related bloggin.


Technorati Tags: idm sun identity compliance

Topic: securing your external offerings with identity architecture.

This may be old hat, but it is missed on many of the architectures that we see.

The next generation of coporate websites (not going to use Web 2.0; not sure exactly where this is) will be more interactive with customers, vendors, and partners.  To date, online company external portals have to be controlled on who has access to what. You certainly don't want to show two customers each others data.  Compliance officers are looking carefully how outsiders get a look at internal system data. The better your control around this, the more you can expose through the website, the closer you can get to your customers.

However, one of the ground rules for external access is to use a DMZ and never put any type of user data in the DMZ. So how to increase personalization and security when you cannot put this type of information at the edge of the IT infrastructure.

Well, as anyone worth their salt should know is to use proxies, both web and directory proxies.  These can sit inside the DMZ and funnel requests to web servers and directories inside the DMZ backwall, where they are safe and sound. Should anyone pentrate into the DMZ, all they will find are servers that are routing requests. They would have to be sophisticated enought to get through NAT'd addresses (tell me you have translated your DMZ IP addresses) and another firewall before they ever got near the company data jewels.

Many architectures don't include proxies because, hey, we already have a load balancer that provides this funtion.  Proxies are more than load balancers. Web proxies can cache static web pages and increase overall system performance.  Directory proxies can control the bind load to a field of LDAP servers and permit you to "dial out" a server from the group for back up and maintenance purposes.

In a future entry, I will discuss how proxies are going to play an even more important role in your architecture.  Don't go cheap now on the initial installation; put the proxies in there. When you need them, they are ready to go.

While there are different styles of managing IT projects, including IdM projects, there are a few good habits you should adopt for your project.

For years, I had a great deal of success following the suggestions of Steve McConnell in Rapid Development: Taming Wild Software Schedules.   Now I am not on the publisher's payroll or shill for the book, but I found it a excellent analysis of why projects in IT go awry and become run away trains (more likely, run away train wrecks).

Note that this is not extreme rapid development, which is a whole dogma and ideology in its own (and not really applicable to IdM projects, in my opinion).

But here are a few suggestions of what to do with the development effort:

1. Change Management in Place - agree to nothing and touch nothing until a change process is in place. IdM projects by their nature drift and change scope almost hourly (on call now where compliance, both HIPPA and SOX, are changing the scope of a project. A procedure to evaluate changes that everyone agrees on, approved before you start.
2. Daily Build -  Keep on instance in Staging that represents the currently most advanced build of software. All developers should check in their code changes each day by 4 PM and it is compiled/deployed and tested by the project lead. Nobody goes home until the site runs as expected. Keeps coders from going off on a tangent for a week and then have integration issues. The bite off smaller changes that can be corrected before the get out of hand.
3. Status Reports - Killer for a project, particularly at crunch time with the deadline looming. Everyone wants to know the status and how close are we.  The daily builds are one way to help.  Point inquiring eyes to the staging site and ask for questions. Team leads - fly air cover for your developers and keep them out of status meetings. Prefer set status meetings every two to three weeks versus weekly - weekly makes status meeting a significant consumer of resources.
   
4. Project Collaboration Site - Think emails and shared network drives are enough to share information? Wrong. Too many moving parts.  Use a collaboration site to track project artifacts (read, the latest version of project documents).  People looking at different versions of project documentation are technically useless.
5. Code Change Control - Take the time up front to build your CVS versioning site. Publish the procedure on it is to be used and how code gets into production. On one project recently where "Steve" was responsibile for production code.  Did anyone not know that Steve was an outside contractor with an expiring contract and also prone to be hit by a bus?
6. Lower the scope of the project - Start small and iterate phases.  Management may have grand schemes, but IdM projects are a journey, not a scheduled trip.  Needs, priorities, and focus change, so have discrete deliveries that build on each other. Recalibrate after each drop.
7. Acceptance Criteria Known Up Front - How does everyone know we are done if nobody knows what will signify victory. Never start a project that does not have a know "ta-dah" at the end of it.  Plus, this keeps everyone's eye on the ball as they are developing. They know what hoops they have to jump through to complete the project.
8. Hire into needs, not when needed - These are fast moving projects with only a 3-6 month window usually. To try and get "a new guy" on board once the project ship sailing will insure the project has qualified skills ready to go.  Throwing addition bodies at a project now adds the heavy load of hiring, training, and integrating into the project. Rather have a highly skilled developer being bored (my fault as project leader) than realize we have to hire a skill set 4 weeks from go live.
   

Hopefully you know these. Never hurts to go through them again.