Provisioning, Fulfillment, and Workflow Engines—Welcome to my world!

These days, I no longer have the luxury of working with Active Directory as a “stand alone” component in the enterprise. My role demands that I view it as part of a comprehensive systems management workflow, and my primary objective is to automate as much of that workflow as possible. Not hard if you’re dealing with a single enterprise, but when you’re automating a workflow that services multiple enterprises—as we do at EDS—it becomes a daunting task. I suppose I’m trying to automate the automation, in a sense.

To add still more complexity, we don’t provide the same services to all clients so I must envision an event driven, service oriented architecture that encapsulates everything from initial request, through delivery, reporting, and billing. It gives me a headache, but it is certainly challenging! There are days that I long to become a Wal-Mart greeter… For the moment, I’m concentrating on provisioning—user provisioning and role based access control. Later, I’ll concentrate on the workflow engine…one bite at a time, right?

Once upon a time, Windows administrators thought that automating provisioning meant writing a script to create new user IDs that were modeled after an existing user ID or an ID template. Now we understand that there’s a lot more to consider than just groups and R, W, X. We know to consider groups, files, applications, delegation, roles, operations, tasks, and so on. I’ve never found a better mechanism for beginning this sort of work than a traditional access control matrix combined with a role hierarchy. Always comforting to start off on the right foot.

Hmmm…first problem: I’m creating role-based access control for multiple enterprises, and few (if any) of our clients will share the same roles. So I’ll have to be very granular in the initial work and create a set of “role components” that will become the building blocks used to create the specific roles for each enterprise client. Then I’ll have to step back and walk through the administrative workflow to find the commonalities across all clients, so that I can further automate administrative processes and tasks. You see, I want to remove as much cost from provisioning and user management processes as possible. So I’ve got to centralize and automate tasks such that I don’t unnecessarily repeat the same tasks for each client (and by client I mean enterprise customer, not device).

I feel another headache coming on. Does anyone know if Wal-Mart accepts on-line applications?!

Assessing an AD Implementation

A co-worker recently contacted me asking if I have any documentation he can use to assess a client’s Active Directory implementation. I do, but because I’d not used the template myself in several months I thought I should review it before sending it out. I’m so glad that I did!

Although I’d used this particular format many times in the past, I found that upon reviewing it, I was not at all happy with the assessment criteria. In the past I had tended to look at an AD assessment in terms of People, Processes, and Tools. Now, however, I find those categories inadequate.

With only a bit of reflection, here are my initial thoughts on changing these high-level assessment categories that I use when evaluating the maturity and effectiveness of an AD implementation:

• Further define the People category to look for efficient and cost-effective staffing models, alongside my previous evaluation criteria that included experience levels, skills, people care, salary bands, and so on.
• Abandon the Processes category altogether, in favor of two new categories: Standards and Workflows.
• Also—and perhaps it’s a nit—replace Tools with Automation. In my mind, “tools” are products and by themselves hold little value. It’s the use of the tools to efficiently and cost-effectively enable automated administration or automated workflows that provides the real value.

Why do I see the need to change the way I view an Active Directory implementation? Primarily because the demands on AD have evolved. In the past, we mostly tended to view AD as a more scalable OS directory, a single sign-on mechanism, or maybe just as a prerequisite for implementing Exchange. (Go back and read your early business cases for implementing AD. I bet those are among the primary reasons cited for adopting Active Directory.) Now I tend to view AD in terms of: 1) identity and access management, and 2) policy-based management of object classes.

Should I be putting Active Directory in the identity management category? I have to, because that is what the market demands of it. Is AD up to the job? Perhaps not, if I consider AD only as an “out-of-the-box” product. But when combined with RC2, Vintela, and MIIS, I believe identity management using AD can be accomplished quite nicely. These are my early musings…I still have to refine the new assessment criteria.

Now what really intrigues me is an implementation that fully automates identity and device provisioning via SMS and BizTalk. But that is an entirely different topic and best saved for another day.