Posted by Ash Motiwala on Wed, Sep 01, 2010
Identropy adds a new offering as part of its well-known Advisory Services: the Identropy IAM Primer Series. This offering not only provides access to Identropy's IAM best practices library, but also provides direct access to an Identropy IAM professional.
Our seasoned Identity and Access Management (IAM) professionals, each with over 10 years of experience in IAM, have created IAM best practices reference documents that capture practical and empirical knowledge in various aspects of the identity and access management landscape, spanning business processes and technologies. They are intended to educate IAM initiative stakeholders of industry best practices and facilitate their adoption in a cost-effective, self-paced manner, thus helping organizations improve their business processes by making optimal use of IAM.
In addition to the best practice documents, the offering includes five hours of direct access to an Identropy IAM professional. Rather than read a static document, customers can also engage in a live conversation regarding the practical aspects of an IAM initiative. This approach will help organizations get started with a specific IAM topic with the practical hands-on guidance that is often missing in IAM initiatives, thereby leading to a more effective approach to adopting and implementing the solution specific to the customer's environment.For more information on this Identropy's IAM Primer Series, click here: http://www.identropy.com/iam-primer-series/
Posted by Ash Motiwala on Thu, Jul 01, 2010
The best part of my job is customer interaction. In the past 4 years, I've interacted with nearly 100 customers, and had the opportunity to see the inner workings of where the IAM rubber meets the road. Real problems, real projects, real solutions. Based on my experiences, I've decided to start a series that shares customers experiences that make a case for Identity-as-a-Service.
Last quarter, Identropy was engaged by a large healthcare provider who had a familiar story. In the previous year, they awarded the services portion of a large IAM initiative to one of the "Big 4" (are they still called that?) consulting firms. After a year and burning through nearly double their original budget, the system was still not functioning as initially planned. Identropy's team was engaged to analyze where the system fell short, make the necessary changes, and get the system up and running (which we did in about 3 months). Last week, Identropy's CEO received an email from the executive sponsor stating how thrilled they were that we helped get them through the finish line. A satisfying feeling indeed, although it left me unsettled.
Consulting Firms Love Complexity
The point of the story (besides tooting our own horn) is that the goal of a traditional consulting firm is to maximize services revenue. In sales meetings, they'll typically focus on their implementation methodology and expertise. Behind closed doors, the story is all about utilization rates and change orders. That's why Consulting Firms love IAM projects. They are complex, and can justify large implementation teams and multiple change orders.
The problem is that I've never met a customer who wanted a long, complex, over-budgeted project. Corporations typically look for predictability in terms of cost, resources and project length. This causes inevitable tension in IAM projects between the consulting firm and the engaging corporation.
Now, I know that I'm generalizing. Many projects are successful and many consulting teams do right by their customers, but that doesn't change the inherent drive of senior partners of the firm demanding consistent billing time from their consultants. After all, that's their business model.
Alignment: A Case for Identity-as-a-Service (IDaaS)
As Frank Villavicencio pointed out in a
previous post, a co-sourced IAM model allows for stronger alignment between the service provider and the customer. In this model, the service provider prefers to provide functionality without complexity, since it's their responsibility to build, integrate, deploy and ultimately operate the overall solution. Since the relationship is a long-term partnership, the service provider doesn't feel the need to take all the money on the table up front. Since the service provider knows that they will be providing post-implementation management of the solution, they opt for a simpler (and in my opinion more elegant) architecture. Ultimately, both parties seek shorter implementation cycles so that they can both benefit from a functioning IAM system sooner rather than later.
For all of these reasons (and more), I believe the days of the "Big 4" approach to identity implementations are numbered.
Posted by Ash Motiwala on Thu, Jun 17, 2010
As with any market, IAM software vendors vie for business by positioning and re-position their software in front of potential customers. Ultimately, the customer selects a vendor, implements the software, and walks into the sunset...right? Wrong.
In reality, things go wrong: Hardware doesn't arrive on time. Design decisions are delayed. Conflicts arise between the software vendor, the customer, and the consulting firm. The software's actual capabilities (read 'limitations') come front and center.
By the end of the first phase, some customers are looking for a way out. That's when the project owner starts googling, "Identity Management Project Pitfalls", and "Failed Identity Management Projects," and starts listening to the sweet nothings of the incumbent sales person who got wind of the project's difficulty. That's when the option of ripping and replacing becomes real.
I can't tell you how many times Identropy is engaged in order to perform a feasibility study on a rip-and-replace project. Unfortunately, due to the limitations of delivery methods available in the market today (as Earl Perkins noted in a recent blog entry), most of the time our advice to the customer is to make specific tweaks to their approach and 'stay the course'. Although it is true that sometimes we may find a real reason to switch, it still has to justify the pain of ripping and replacing an IAM solution. Here are a few reasons why:
- IAM is Invasive! There are connectors from the IAM system to all the target systems in your environment. Many times, we'll find poorly architected (and overly customized) solutions that place a tremendous amount of dependency on the target systems.
- Lack of Standards: Unfortunately, there is no generic industry standard for interacting with target systems. Each IAM vendor has their own 'Connector Framework'. A rip and replace would have to 'recreate' many of nuances specific to the platform that was just deployed.
- Re-Educating End-Users: Getting end-users to change their behaviors the first time was hard enough!
- Trading Deficiencies: For many customers who have gone through a rip-and-replace, they have come to find out that the deficiencies they were running from from the replaced software vendor exist in another form in the new software.
-
They're Expensive: Replacing IAM software is more expensive than most customer's initial estimation. After taking into account the new skills that have to be learned, changes in hardware, software, the investment in end-user training, etc. the cost is often equivalent (if not more than) the cost of implementing it the first time.
For these reasons and others, we strongly suggest our customers to perform a workshop feasibility study on the effort of ripping and replacing before pulling the trigger. Get an outside consulting firm to take a look and validate your approach. It shouldn't take very long (a week or so), and their insight may save you significant time and money.
Posted by Clint Finch on Thu, Jun 03, 2010
Based on my experience, most Identity and Access Management (IAM) consultancies - even the "Big 4" - tend to keep clients in the dark. Due to the complexity of IAM projects and multiple stakeholders, it's easier to hide the gory details of a project gone wrong u
ntil its too late. Unfortunately, this approach has given the IAM services industry a black eye.
As an organization, we are big believers in transparency for our clients. Transparency not only aids teams to work through project curve balls, but it also empowers the teams to spot risks collectively in order to prevent them from ocurring in the first place.
As I write this post, Identropy is now in its' fourth month of everyday usage of our Project Management Information System (PMIS). When I initially joined the team, we were using a mix of disparate tools: SharePoint for document management, a Time Tracking application, MS Project and Excel files for resource and expense management. Individually considered, our disparate parts did what they were supposed to, although none of these tools really talked to eachother.
In our quest for increasing transparency for both ourselves and our clients, the lack of integration of our various systems caused significant overhead for our PMs. They had to spend time to create the level of transparency we wanted our clients to have. In order to address this inefficiency, we decided to look for a better solution: a single place for our customers to have total visibility into our IAM project progress, cost, risks, documents, etc.
Simply stated, Identity & Access Management projects require strong and active project management. And while technology is never a good substitute for solid processes, our experience is that 
an effective Project Management Information System (PMIS) can put your IAM project on steroids by increasing transparency into the state of the project.
Since I had experience using an Enterprise wide PMIS tool, I led the effort of defining our requirements and identifying likely candidate solutions. In one of my earlier blog postings, I wrote about the
importance of a good Requirements Traceability Matrix. So, the first thing I did was begin working with my team to start evaluating just what requirements we really had for a PMIS. I constructed an RTM and began consolidating requirements into various components such as "Financial Tracking" "Scheduling", "Calendars", etc...
Our key criterion boiled down to 3 major points:
- Proper Task Sequencing: In a typical IDM project, one task must drive another. Without this, you simply have a glorified to-do list, which any IDM PM knows is the kiss-of-death for the project.
- SaaS Based Solution: Identropy is a zero IT footprint company. That means, unless absolutely necessary, we don't have anything on our premises.
- Integrated Time Tracking, Doc and Expense Management: By integrating all of these components, we would have greater insight into projects, resource utilization, and how much we were spending.
The fun part in performing requirements assessments is discerning marketing hype from reality. (We have a lot of experience doing this for our clients when selecting an IAM platform!). The finalists demonstrated complete packages in terms of polish, solution feature sets and, to some degree, cost flexibility. Ultimately, Identropy chose Clarizen to partner with to provi
de our PMIS solution, for pretty much the same reason most organizations select Identropy as a partner. While the Clarizen solution is top-notch, the overriding-factor was and still is the people and their philosophy. From our account rep (Jacqueline, call her if you need a PMIS!) to our product support folks (Gil and Josh), it would be almost impossible to find people who truly care as much about honesty and earning a client's business as they do.
The impact of the overall solution has been great. Our clients have welcomed the increased visibility, which has allowed us to forge a closer partnership with them. It has increased communication between consultants, resulting in fantastic conversations regarding our implementation methodology. Lastly, it has served as a differentiator for us in front of potential clients that shows the practical angle of our corporate philosophy regarding transparency.
Posted by Clint Finch on Tue, Feb 23, 2010
In continuation of my last post about the "business" aspects of an IAM project, this post will discuss two of Mark Dixon's "Ten Best Practices for Identity Management Implementation." Specifically, points 2, "Secure Sponsorship" and 4, "Select Project Leadership".
Projects, by their very definition (according to the PMI), require a sponsor. After all, the sponsor authorizes the execution of the project and funds it. So without a sponsor, you don't officially have a project. But, if you dig into Mark's point on sponsors a little deeper, you'll see that there's more involved in being a sponsor than just funding the project and showing up when it's complete. Indeed, if you have a complex, enterprise wide IAM project, this model of Executive Sponsorship will certainly protect your project should it encounter turbulent waters that may well sink it. While it isn't your Executive Sponsor's responsibility to directly manage the project, he or she must be involved enough to provide the necessary leadership to the Project Manager so he or she can successfully navigate the many diverse challenges and obstacles in implementing a IAM solution.
In today's IT environments, it seems we're constantly on the move; updating the company's key applications, replacing old hardware, or putting new security measures into place, etc... Because our environments are in constant flux, it can be particularly difficult to successfully implement enterprise wide projects that are also cross functional in nature. This potent combination, competing agendas and uncertainty, make enterprise IAM projects more complex from the onset. Strong Executive Sponsorship is required to overcome the obstacles that seem to come built-in with an IAM solution.
On the other hand, poor Executive Sponsorship makes a tough environment for your project significantly more difficult. In an informal poll I conducted of IAM and Project Management professionals - colleagues with many years of experience in the field, the fall-out from poor or absent Executive Sponsorship is clearly seen. It typically results in a lack of visibility for your project, a reduced priority among the sea of competing initiatives, failed escalation paths and a strong potential for cost overruns. As a PM, you must ensure your Executive Sponsor understands the full scope - from a technical and business process perspective - of your IAM implementation. The Executive Sponsor must know where the potential troublespots are and where leverage is needed to "move" obstacles to the project. Often, Executive Sponsors will appoint a representative from senior management to act in their stead. As a PM, ensure he or she is involved in your project and is apprised of risks and issues on an on-going basis and able to take action and act effectively. Ideally, as PM's, we must be aware of the "quality" of leadership we are getting from our Executive Sponsor and the resulting impact - good or bad - to our IAM implementations. It is our job to keep them apprised on a regular basis and to provide that information in a format easily consumable by Executive Sponsors. Think Red-Yellow-Green (RYG) charts, regular status reports etc...
By taking proactive action to keep the Executive Sponsor informed and in the loop, we can significantly improve our odds of a successful implementation.
Posted by Clint Finch on Mon, Feb 01, 2010
As a Project Manager here at Identropy, I've been given the challenge and opportunity to share my thoughts and experiences with you regarding Identity and Access Management from the eyes of a Project Manager with on-the-floor experience. While Ash has shared his expertise regarding IAM roadmap development and how to determine if your company needs one or not, and Frank has shared his thoughts on the direction of IAM-as-a-Service and where it's going and how it's evolving, I'd like to spend a little time in these first posts talking about the "business" side of IAM.
Ideally, my life as a PM of an IAM project starts where the IAM workshop leaves off. I am handed the organized findings of the workshop that include business drivers, use cases/general requirements, a high level architecture and Identity Management roadmap. My first order of business is always challenging: to 
orchestrate interview sessions with client stakeholders in order to create an RTM, or Requirements Traceability Matrix. A good way to define stakeholders is to think through the processes that were defined in the workshop, and identify all the "touchpoints" throughout your organization, for example HR, Support Center, Desk-side Deployment, System Engineers, etc., and begin to involve them. (We also have a stakeholder definitions doc you might benefit from.)
For each of the interview sessions, prepare questions that can unearth (and differentiate) business requirements, functional requirements and technical requirements from the project stakeholders. It is absolutely critical to remember that the goal here is not to architect the solution, but rather to define just how big the elephant is. Don't let your organization be the blind man that defines the elephant based only on sensing the trunk or tail of the elephant.
For example, you might choose a self-service component of IAM to develop a use case that would walk through the process your end user will go through upon first logon after successfully being provisioned to a new LAN account. Using our first logon example, we would expect the Support Center would have requirements for the process related to delivery of the initial password, or perhaps what information is relayed to the user regarding Support Center services. We would expect that your HR department might have a requirement of the process that the user not be able to logon until they have been fully processed in the company's HR system. Perhaps your Information Security team will have requirements that place certain constraints on how your end users are initially provisioned to various target systems. Each use case that is developed to meet the needs of your business drivers will have requirements. These requirements should be listed in an RTM to include the requirement itself, the originator and/or owner, prioritization and general summary of what business driver it can be traced to and how it addresses this driver. As a note of suggestion, requirements should be as succinct and discrete as possible. IAM programs tend to have many moving parts, and tracing requirements necessitates that each requirement be a discrete element. Following this advice may balloon the overall number of requirements you have, but increase your visibility and traceability, which is extremely valuable.
The importance of an RTM cannot be overstated. It directly feeds your Work Breakdown Structure (WBS) and will be invaluable down the road in your IAM project as a guide to the scope of the program and who owns which requirements.
Lastly, I benefited from a few blog entries on the subject in the blogosphere I'd like to share:
10 Best Practices for an IDM Implementation by Mark Dixon
2 Approaches to IDM Project Methodology
In our next discussion, we'll continue discussing the business aspects of an IAM solution and the pitfalls/roadblocks your company will need to look out for in order to increase your chances of a successful implementation.
Posted by Ash Motiwala on Mon, Nov 30, 2009
Since we've performed more identity management workshops for our customers than I care to count, I thought a blog series was in order to provide some of our insights into aiding corporations develop an Identity Management Roadmap (which is a step by step guide for your organization to follow when deploying an identity management solution). I got a chance to sit down and interview some of our 10+ year identity gurus to collect some of their golden nuggets of identity wisdom for this series. Heck, this may even inspire and enable some of you ambitious folks out there to develop an IDM Roadmap for your organizations yourselves!
But I Don't Think I Need an Identity Management Roadmap
...and you may be right. Here are a few pointers that might indicate that an Identity Management Roadmap might be overkill for your organization. If you have a very specific itch that needs to be scratched but nothing more than that, then you probably do not need an IDM Roadmap. An example of a localized itch is if your organization just got slammed on an audit for "orphan accounts" in AD, but everything else was in perfect order. Another example is if you work for a healthcare organization that needs SSO to appease the docs who have to remember 25 different usernames and passwords for various applications, but everything else is in good shape (i.e., identity data integrity looks good, user access recertification processes are fine, etc.). In situations like these, find the right technology and apply it. Simple as that. At most, you'll need an afternoon whiteboard session with an Identity Management specialist to help you compare the pros/cons of the various toys in the identity toolbox that can solve your problem along with a cost analysis of software and services.
Why do I need an Identity Management Roadmap?
If you have more than a few identity related problems that you are trying to solve that may require more than one identity management software component, an Identity Management Roadmap will be critical for successfully putting a solution in place for the following reasons:
Architecture: Too often, we perform an Identity Management Assessment for a customer that already has an Identity Management system in place and find a hodgepodge of technologies poorly assembled together into what they deem their 'Identity & Access Management System'. In most cases, the various components of the system were deployed in isolation of each other, often times by different teams. Each team thought they had an isolated itch, purchased software, and deployed it. The result is a poorly constructed system that is repeatedly taped together with 'customizations'. The process of developing a roadmap will avoid such an end. A good workshop will identify stakeholders across your organization, set up interviews, and systematically find itches (use cases) corporate-wide. The result will be a better architecture that satisfies your organizations requirements as well as stands the test of time.
Pitfalls: The process of developing a roadmap will help you see the big-picture of your organization's requirements and strategic direction. This can ensure that your efforts don't get sidetracked by tactical endeavors, something that can easily occur without a roadmap to guide you. Identity Management initiatives are full of technology related time-sinks that give techies a 'really cool problem to solve,' but may not be a part of your corporation's business drivers. From another angle, a roadmap forces you to think strategically, taking timeline into consideration and focus on identifying time-sinks up front.
Exploit Your Software: The process of developing an IDM Roadmap will require a technology assessment of your infrastructure. Often times, we perform an Identity Management Assessment for a customer and find plenty of existing software that can be used to satisfy some of the client's requirements. It wouldn't be an over-exaggeration to state that on average, corporations use less than 20% of the capabilities of the IDM software they purchase, usually due to a lack of understanding the product's capabilities. The process of developing an IDM Roadmap will help unearth valuable software that you already own and could perhaps leverage in your identity initiative. How great would it be to find out that you could spend less on software because you could leverage what you already own?!
There you go. Three solid reasons why you should develop a roadmap prior to implementation. As you might have noticed, there are a lot of pre-requisites to the IDM Roadmap. That is the topic of our next post in this series.
Posted by Adrian Rodriguez on Wed, Jul 15, 2009
I recently read a number of posts where managers were fighting it out about how unique an Identity Management Project really is and sometimes I truly think that people forget that this is an Enterprise Implementation with many diverse moving parts. Dealing with an entire enterprise no matter how small the subset of users brings a large number of difficulties that could lead even the best of project managers to lose their hair.
The most successful managers have a combination of soft skills, analytical skills revolving around business process management and a high level understanding of security and directory technologies. Some would consider these skills plain vanilla but when you disect each deliverable sometimes being dependant on so many areas which you have no control over and the task of plotting out deliverables such as connector development which will have end user visibility only when workflows or other features are in place leads me to think otherwise. These constant transitions could be quite tricky and from the way I see it could be considered quite unique.
In a nutshell the conclusion on all of the posts was that IdM Projects are unique but so are projects in other industries. Basically paraphrasing an old saying..."if you have to ask how much something costs you probably can't afford it" just the same as if you have to ask why an Identity Management Project is unique...
Posted by Ash Motiwala on Tue, May 05, 2009
In my last entry on Identity Management Project Scoping, I wrote about putting together a "PUT" chart, and creating Business Process Correlation sets. If you have been following along, at this point you should have a pretty telling matrix of processes, user populations and target systems, along with correlations and priorities.
Here is the next step...
Step 3: Provide a Non-Technical Description of Each Process
This one could be a bit time-consuming, but well worth it. For each Business Process Correlation Set, provide a short non-technical description of the process flow from beginning to end. For a more detailed method of describing the workflow, create a table that follows the template below (a sanitized example from one of our clients):
...
At the end of this excercise, you should have a pretty good handle of what business processes you are looking to automate, the target systems, the user popuations, the priorities, and a good grasp of the process as it stands today.
Typically, the total set of data that you have completed will need to be broken down into a phased implementation. An Identity Management Consulting firm should be able to guide you in the process of translating the results of the scoping excercise above into an Identity Management architecture, help you find a solution that works for your specific requirements, as well as help you put together your very own Identity Management Roadmap (yipee!). All fun stuff, and good practice when engaging in an Identity Management project.
Posted by Adrian Rodriguez on Thu, Apr 30, 2009
Our goal is to keep you informed and highly educated on identity management solutions, trends and business.
Identity Management Solutions 101: User Provisioning
Identity Management Solutions 101: Password Management
Identity Management Solutions 101: Enterprise Single Sign-On
Identity Management Solutions 101: IaaS (Integration as a Service)
Stay tuned for more sessions about topics such as Deprovisioning, Cloud Computing, SOA and others.