Category: project management

Managing IAM middleware

middle

There are a lot of different jobs in IT.

My first few positions were in software development. Then networking and infrastructure, and a bit later on, along-side security teams. When I was introduced to IAM in 2003 (then called ‘authentication and authorization’) it was so new there wasn’t a nice, tidy category for it. A few years later, I noticed Oracle had put IAM in a ‘middleware’ bucket so I guess that’s how we’ll refer to it — even if Wikipedia describes middleware a bit differently.

Implementing IAM middleware isn’t an overly natural thing to do. It isn’t the same as the standard application development, server rack upgrade or firewall install. So it can be useful to consider IAM projects and operations in comparison to these three common IT activities:

  • Software Development — Like application development, IAM has to consider user requirements including usability, attributes and business rules for data. BUT developing a single system is far easier than implementing IAM. There are more system integration points — it is middleware — making it technically more difficult. For a project manager, IAM also has more project teams to coordinate. For example, I’m currently working on a provisioning initiative that has five technical delivery teams and spans two large organizations.
  • Infrastructure — IAM typically (if not always) involves a directory, and directories, notably Microsoft AD implementations, are paired with operating systems. Infrastructure changes to these operating systems impact IAM and vice-versa. The big difference between IAM and infrastructure projects is that IAM middleware requires tailored configurations and/or custom software components. In a large organization, standard infrastructure (or infrastructure services) can meet their needs. IAM is not so standardized as the management of identity is more closely tied to business needs and strategy. Assuming
  • Information Security — Protecting privacy and access to information is part of both the IAM and security worlds, and IAM is often described as a sub-set of information security. But IAM is about letting people in and the remainder of info sec is about stopping access… Implementing IAM requires an understanding of these two different views in order to create solutions that meet compliance requirements while still meeting user needs for access.

Managing IAM middleware well is the goal and understanding the differences between IAM and traditional IT practice areas is key to successful projects.

Mike

 

 

Old job, new job

It has been a while since I’ve had a new ‘primary’ contract so I thought a post on the old and new is in order.

Since 2007, I’ve been the IAM Program Manager for the Alberta Government department of Innovation and Advanced Education. We assembled a development team to build a new IAM solution for the department’s growing online services. Web applications for post-secondary students were the main priority but business partner access to online services and SharePoint sites was also required.

The solution was built on top of Active Directory Federation Services (AD FS) and was developed in .Net. The services developed include self-service registration, authentication, authorization, identity proofing, access administration and reporting. We call it the Secure Identity and Access Management System, or SIAMS for short.

Today, that IAM solution has 650,000 identities, processes over 100,000 logins per month and supports 35 business applications. It supports a host of self-service features like password reset via SMS, and can deliver up to LoA 2 identity proofing.

I’m proud of the team that put the system together and very appreciative of the support I received from Innovation and Advanced Education’s management over the years. Code Technology will remain on the job with Dallas Gawryluk taking over the reins in an expanded project management role.

My new position is as a Systems Integration Project Manager with Alberta Health Services. The IAM solution on this project is quite different, and the job I’m being asked to do is already both interesting and challenging.  Working with multiple teams, I am hired to plan and deliver an implementation of an enterprise IAM solution for clinical users and access administrators.

New faces, new issues — and after seven years, a slightly different commute to work. I’m looking forward to the next year!

Mike

The case for less ocean boiling

I don’t know who invented the term ‘boiling the ocean’ but it is a great description for projects that are too large, too ambitious and, ultimately, headed for failure.  Identity management projects run the risk of being setup to fail because their sponsors are trying to boil the ocean.

The problem lies in the scope of a typical IAM project.  These projects can often try to do far too much — the sponsor and project manager confuse the bigger, long-term goal with the project objective.

In a IAM strategy report I completed last year, my recommendation to the client was to use a phased delivery approach:

Smaller projects are easier to manage because they have a single focus and set of outputs to produce.  Adjustments to follow-on projects can be made based on lessons learned.  And with shorter projects, management can more frequently see the real results as each project completes – reports/briefings can be written and financial benefits documented.

Since 2007, I’ve been working as the IAM Program Manager for another client and putting these ideas into practice.  This program has been established with eight releases.  Each release is a project that runs between six and eight months, depending on the current needs of the business and our sponsor.

The key for keeping these projects short is scope management. The scope is determined a month or so before the project starts.  Inevitably, we get a change in scope sometime in the first few months — a new application needs to be integrated, the auditor wants a critical feature added, etc.

As any project manager knows, the triple constraint means that if you increase your scope, you can either extend the project schedule or add resources (and cost) to get the work completed on time.  This triple constraint is often addressed by clients by pushing out the schedule.  This also increases cost of course, even if the team size stays the same.

My philosophy is a bit different.  I look to trade off scope for… scope.  If six weeks of extra work are added, I will look to see if six weeks’ worth of scope can be removed.  Lower priority work can often be removed from scope and planned for the next project.

In other words, I want to keep the project schedule and costs fairly static so that the team can focus on an end date — and, by extension, new work and a new project after that date.  In a longer term program I place a lot of value in delivery.  The sponsor needs to see solutions delivered and projects closed.  We must be able to report to senior management actual business value and a list of real accomplishments, not just the percent complete on a project.

The end results are higher team movtivation over the long haul — in three years, I have had zero team turnover — and better, more measurable business results.

Mike

IAM in 2010?

It has been a busy, busy past few months for Code Technology — new projects, new opportunities and a growing business.  This post provides an update on our project work with, necessarily, client names obscured:

  • Last fall, the  Identity and Access Management program that I’ve been leading for a large public-sector education organization paid some big dividends.  Over the past two years my team has been building an IAM system on top of Microsoft’s Active Directory Federation Services (ADFS).  The main work was actually completed over a year ago, and the first web applications with a few hundred users were launched.  But in October 2009 the wider deployment started and we now have over 35,000 users, with as many as 120,000 users to come online in just over three years.  By the end of 2010, we could have a dozen applications using the service, enabling access to the broader education sector in Alberta in ways that have previously been impossible.
  • We recently completed an IAM strategy and program development project for a very large organization (85,000+ employees) here in Alberta.  This enterprise has some compelling identity challenges and high security needs.  What is interesting is that we have been able to construct a strategic framework, then drive out enough detail to define individual IAM projects for inclusion into their overall information security program.  I strongly believe that defining strategy without a defined delivery program as part of the report is useless — how many strategies and architectures do we see that end up sitting on executive shelves? With this project completed, the client now has a clearly articulated strategy and a practical set of projects defined in a format that is easily understandable by business and technical decision-makers alike.
  • We have also been working to develop the Canadiam blog and online community.  So far we’ve managed to create the blog site, populate it with a few posts, create a Twitter hash tag (#canadiam) and setup a LinkedIn group.  We are always open to new commenters, guest bloggers and other contributions so if you are interested in this niche slice of Canadiana, visit the site and let us know!  At the very least, feel free to slap #canadiam on to any Tweets you have related to IAM in Canada.

There really seems to be an increased rumble in the IAM services space — I’ve been at this niche for over seven years and I don’t recall a time when there have been so many implementations in the works. Whether it be government, other public sector or for-profit enterprises, IAM seems to be on everyone’s mind.

In the past few weeks alone, we have had interest in Code’s IAM services from three different provinces — five different projects in total. And that’s just what a crossed my desk — there are at least three major IAM implementations being planned or being delivered in Alberta at present, renewed federal efforts to develop the Pan-Canadian framework, another major project in Manitoba and (from what I can gather) similar initiatives in the other western provinces.

There is a lot going on in the identity world.  Will 2010 be the year that IAM makes a big splash across the country?

Mike

 

Managing tough security projects

For most of the past four years, I’ve found myself in project management positions on security projects.  The work has included managing technical and business teams as they integrated applications into an enterprise Identity and Access Management solution.

These projects have been among the most difficult I’ve had to manage with most of the challenges came from managing multiple teams.  On each of these projects, successful delivery of the work required cooperation from multiple disciplines: business analysts, software developers, infrastructure guys, core integrators, vendors, security analysts and privacy analysts.  On the larger projects (e.g. gov’t healthcare or education) there were up to seven teams involved, often from three or four different organizations.  And, of course, each organization had its own project sponsor and senior management teams to please…

Perhaps enterprise IAM is unique in terms of implementation complexity.  The client organization (government) certainly was complex, and the public-facing nature of the IAM solution required care in planning and execution.  The technology we chose was complicated and new.  The solution was highly distributed.  Our vendors over-committed and, frankly, under delivered.

I found that it was critical to focus on delivery and manage that delivery formally.  For those projects where we used this approach, we were successful.  For others, well, the results eventually were produced but not without hardship and delay…

Mike