When is a Virtual Directory not a Virtual Directory?

The answer is simple, when it is used as a Web Server Proxy rather than an LDAP Proxy.

Let's look at the classic definition of a virtual directory (in the interest of full disclosure, this is from the SAP VDS whitepaper)

"The Virtual Directory Server can logically represent information from a number of disparate directories, databases, and other data repositories in a virtual directory tree. Various users and applications can get different views of the information, based on their access rights. "

So what does this mean?  We're taking various sources and putting a LDAP front end on them.  Now what can these back ends be—databases, directories, other virtual directories, etc.  The connections can take the form of ODBC, XML, or other web services.

But what happens when we do web services on both the front and back end of the VDS?  Well, I do not think it is really a Virtual Directory any more.  We're not representing information in a Directory form and we're not doing read/search operations.  It certainly would seem to put the never ending cache debates to bed as well.  I'm thinking that what we now have is a web services proxy; or in a more mature implementation, a Virtual Application Server.

So how the VAS would be used?  Simplest case would be to have an application make a request to a VAS for information.  This information is available from another VAS connected system via some mapping logic that would be able to tell VAS where to find it. With this information delivered to the targeted system the proper information is obtained and returned to the requesting application.

You would have to wonder how often something like this is needed after all, web services connectors can be written easily enough.  However, what happens when we do not have all the code or if there’s a need to segregate the request over multiple domains or firewall zones.  That I think would be one use case for the VAS.  Another would be when there is no direct connection say, between a role management system and a provisioning system, two common IdM applications these days.  This could open up completely new ways for systems to interconnect.  I wonder if anyone has been thinking along these lines.

Managing Project Communication

I've written before on the topic of how to prevent project failures, but very little about what happens as projects are failing. I was recently chatting with some colleagues about what does happen when a project begins to head south.

First of all, there always seems to be a tendency to blame the outsider. Basically this argument looks something like: "You never got the requirements right (from the customer) / you never delivered correct requirements (from the consultant)"

What does this boils down to is a failure in communication. Now the question from a risk management approach is how one keeps this communication in sync. Based on our discussion we came up with the following:

• Regular status meetings. If your executive sponsor is not at these meetings, schedule regular steering committee updates which should be just the project manager(s), architect(s) and the executive sponsor. They might not need to be weekly, but they must not be optional any of these people. Do not rely on only one side to make these reports.  Everyone must be on the same page. Make sure the sponsor is aware of the key challenges so that there are no surprises.
  
• Obtain consensus and settle the issues quickly and decisively. If there are dissenting opinions about major decisions, get the issue settled once. Don't keep circling on the issue. If there's an issue that just won't go away, get the parties in front of the executive sponsor as I've noted above. Get a final ruling and move on.
  
• Establish change controls. For some reason, no one likes to use these. There's a feeling that these are things to hide behind, rationalize additional cost or bog down the project in extra paperwork. None of these are true. All that's being done here is making sure that all project principals are aware of the change. This establishes responsibility and sets up controls for making sure that things don't get out of control. And I'd imagine that the amount of paperwork involved in a change control is minor compared to having to write the report of why the project failed. Trust me, this is not fun.
  
• Use and establish some sort of project strategy/methodology. I don't care what it is, but make sure a project plan exists and that there is structure in place. There should be a project manager who will make sure that there is a plan to complete the project, but the architect and senior engineers should make sure that there are development standards which must also include documentation!
  

These points are intended to increase communication and decrease mistrust and politics. If the project team meets regularly, tracks what they are doing and how the project changes and has a structure for managing progress and change there is less of a chance of having a post-mortem and more of a chance of documenting the best practices that were done right!