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.

Why should you care?

Before I go too much further in discussing the ways and means of automating and improving the use of Active Directory, perhaps I should talk a little bit more about the “why” of doing so.

Implementing and managing Active Directory can be an expensive undertaking. While Microsoft originally touted Active Directory as a great way of lowering your enterprise TCO, I’d bet that many organizations are actually spending more on administration now than they did before they implemented AD. Does that mean Microsoft was wrong? No. It means that we’re not fully utilizing the features and capabilities of AD, thus adding cost to our administrative budget. Yes, you heard me correctly. I firmly believe that, if implemented incorrectly or incompletely, Active Directory will add to your Total Cost of Ownership (TCO).

Let’s take a closer look. First, I bet many of you are still running NT servers in your Windows 2000/2003 computing environment and are likely still in mixed mode. Thus you’re not able to take advantage of the full functionality of AD. Cha-ching $. And you’ve probably not yet gone through the time consuming effort of implementing a comprehensive model for use of Group Policy, which means you’re still manually performing functions that could be automated. Cha-ching $$. And have you integrated AD with your HR application to automate role-based user provisioning/de-provisioning? Cha-ching $$$$ (user provisioning, frequently called Change-Add-Move or Move-Add-Change, often represents up to 40% of your TCO in a large environment). Did you adapt your system administration staffing model to fit the new workflows enabled by Active Directory, or are you using the same staffing model you used when performing NT administration? Cha-ching again $$$.

I could go on, but I’m sure you’ve understood my point already. These examples illustrate exactly how an organization ends up spending more by implementing Active Directory. Unless we adapt to make good use of technology tools like AD, we’re simply “putting lipstick on a pig”. (I hope that phrase is recognized outside of Texas. I once described someone as “all hat, no cattle” to a friend from Michigan, and he’s still laughing at me.)

OT: Dodgeball

Has anyone out there tried Dodgeball? I am a rabid user of LinkedIn for professional networking, but haven't yet made the leap to social networking. And Dodgeball takes things a step farther, no? I'm intrigued. But I wonder about the downside. Would love to hear anyone's experiences, whether good or bad.

Active Directory Group Policy

I’ve already opined that we technologists have had the wrong focus on AD for the past several years. Based on my extensive background in providing outsourcing services, my methodology for designing and implementing Active Directory has always been based on how AD will be managed. Anyone who has managed an enterprise with hundreds of servers probably has a similar focus. But when you’ve managed multiple customers with hundreds of servers each, constantly honing administrative efficiencies becomes a calling. So after the initial challenge of learning Active Directory design basics, I quickly moved on to focus on using AD as a tool to streamline administrative work. And that is where I believe we should all be focusing now.

The most obvious means of gaining administrative efficiency is by managing users and objects through the use of Group Policy Objects. Yet I find that within most organizations, defining and managing Group Policy is considered a tremendous chore. Many administrators strive to minimize the number of GPOs in the environment, instead relying heavily on manual or scripted methods of managing users. When Group Policy can provide such tremendous administrative efficiencies, why aren’t more of us using it extensively?

I believe administrators shy away from Group Policy because they view it in an incomplete context. Group Policy should be seen as only one expression in a larger mathematical statement that ultimately equates to Policy Based Administration. Group Policy is the technology component of the equation, and will never equate to Policy Based Administration (PBA) by itself. We also require a clearly articulated model and corresponding policy definitions to make the equation add up. To prevent Group Policy Objects from becoming an additional administrative burden, we must first define the model we’ll use to achieve PBA and then define the policies that enable us to achieve the model. Group Policy is simply the technology, or tool, that enables us to deliver the model.

Beginnings

Let’s don’t get into the Directory Services Wars here…each has its own merits and followers. AD just happens to be the directory service in which I specialize. I’m sure we all know that there are scenarios in which AD excels, and those in which it plays a supporting role. Onward…

I fondly remember Microsoft’s Windows 2000 launch event in San Francisco back in February of 2000. The major IT vendors had booths in the exhibition hall; CTOs of major corporations were wined and dined; and media analysts were thick as bees on honey. It was a Microsoft geek’s paradise—the whole industry was focused on Active Directory and those of us with early experience had our fifteen minutes of fame on center stage.

The industry has seen a lot of technology come and go since Active Directory was introduced. Most IT professionals, including those at Microsoft, will tell you that after 5 years on the market Active Directory is a mature and broadly implemented product. While I agree that it is widely implemented, I don’t agree that use of Active Directory has reached a mature stage of life. In fact, I think few organizations have begun capitalizing on the promise of Active Directory.

In my consulting life, I’ve dealt with some of the world’s largest corporations. Most of them use Active Directory simply as an authentication mechanism, and as an entry point to recent versions of other Microsoft products such as Exchange. They do not take advantage of the policy-based management, role-based management, or identity management capabilities of AD. Many (many!) are still supporting Windows NT. I’d go so far as to say that most still have “entry level” implementations of AD.

Anyway…since I work with it and sometimes write about it, I tend to think about AD a lot. I’ve even developed an AD maturity model that I use to rank an organization’s implementation of AD. This helps me to pinpoint areas for improvement and provide advice on how the client can gain efficiencies and reduce costs—bread and butter work for a consultant.

With over five years of exposure to Active Directory, shouldn’t we be talking about a lot more than simply how to design AD forests and trees? I say we move on and talk about more current issues such as policy-based management, identity management, AD’s role in a service oriented architecture, and so on. And I always love to hear about cutting edge implementations.

If you’re not interested in current Microsoft technology, you’ll obviously find this blog very geekish. But if you too deal with it on a daily basis, perhaps you’ll join me here for some interesting (albeit geekish) conversation.