Identity Management: Observations from the Trenches
0 Comments Published by John Dillard on Monday, June 26, 2006 at 4:01 PM.
Identity Management is often treated as an IT project, when in reality it is a combination of business process redesign, regulatory compliance, and IT infrastructure. We find that our clients are increasingly taking on identify management as a strategic initiative of the business, and making smart decisions about IDM strategy is critical.
Identity Management begins with a proper foundation Identity Management has been around for several years offering organizations the benefits of reduced IT administration, improved security, and efficient auditing and reporting tools to meet regulatory requirements like those dictated by Sarbanes-Oxley. Although the benefits of Identity Management are compelling, many organizations struggle to develop a solid infrastructure before jumping ahead to pursue more high value projects. It’s like building a house before your foundation has been properly completed; this is always a bad idea.
What brought us here in the first place…
Organizations experiencing rapid growth often find that their existing manual processes and tools are no longer adequate to get the job done. For large organizations, the IT staff will create, delete, and modify accounts for tens of thousands of people a year. Are these the kinds of activities your IT staff should be spending the bulk of their time on?
Worse yet, Sarbanes-Oxley compliance requires the ability to audit your systems and know who has access to what accounts. In many cases, contract labor or additional IT staff are hired to comb through systems and remove orphan accounts, revoke access to unauthorized users, and ensure that generic and admin accounts have not been misused. At the end of the day, throwing more bodies at these issues isn’t going to solve the underlying problem – manual processes don’t scale.
This is not just another IT project
Unlike a server consolidation project, or upgrading an email platform, Identity Management (IdM) has a broad scope that affects both business processes and IT systems. Partnerships will have to be built across internal IT silos (networking, security, UNIX, mainframe, user applications, help desk, etc.) as well as with the business. The most important relationship on the business side of the house is with Human Resources, which controls all employee data (job title, department, manager, location, contact information, etc) and owns the hire and termination processes that affect the account management lifecycle.
Identity Management relies on triggers in the enterprise ERP system to create, modify, disable, and delete accounts in all connected systems according to well-defined business rules. Thus, an employee hire will automatically create a user identity, assign the user appropriate accounts, and rights, for their role and then turn around and remove that identity and delete accounts when the employee leaves. Clearly, there is a lot more complexity involved here than simply slamming in a new application and training a few users.
Doing it right the first time
A common problem with Identity Management projects is that organizations want to jump ahead to realize the benefits of IdM, without having built the foundation required to support the solution in the first place. This is tactical approach that attempts to cherry pick the high value projects, without building the fundamental components of the solution first.
One common shortcut to this end is placing a special purpose directory in the position of metadirectory. The special purpose directory is one intended to support a particular system, say your SendMail application. Its user objects, schema, namespace, and architecture are tuned to manage accounts and user data for that application, but are not designed to perform the same function across multiple systems. In the end, organizations run into issues with data quality, application integration, and scalability. They often find that the directory structures that worked well to support an application are not fit for an enterprise class solution.
“Doing it right” means having the discipline to build out your core IdM infrastructure before tackling high value initiatives like provisioning, single sign on, and automated workflows. Big Sky Associates recommends establishing an Identity Management strategy and road map and having the discipline to follow it.
Identity Management begins with a proper foundation Identity Management has been around for several years offering organizations the benefits of reduced IT administration, improved security, and efficient auditing and reporting tools to meet regulatory requirements like those dictated by Sarbanes-Oxley. Although the benefits of Identity Management are compelling, many organizations struggle to develop a solid infrastructure before jumping ahead to pursue more high value projects. It’s like building a house before your foundation has been properly completed; this is always a bad idea.
What brought us here in the first place…
Organizations experiencing rapid growth often find that their existing manual processes and tools are no longer adequate to get the job done. For large organizations, the IT staff will create, delete, and modify accounts for tens of thousands of people a year. Are these the kinds of activities your IT staff should be spending the bulk of their time on?
Worse yet, Sarbanes-Oxley compliance requires the ability to audit your systems and know who has access to what accounts. In many cases, contract labor or additional IT staff are hired to comb through systems and remove orphan accounts, revoke access to unauthorized users, and ensure that generic and admin accounts have not been misused. At the end of the day, throwing more bodies at these issues isn’t going to solve the underlying problem – manual processes don’t scale.
This is not just another IT project
Unlike a server consolidation project, or upgrading an email platform, Identity Management (IdM) has a broad scope that affects both business processes and IT systems. Partnerships will have to be built across internal IT silos (networking, security, UNIX, mainframe, user applications, help desk, etc.) as well as with the business. The most important relationship on the business side of the house is with Human Resources, which controls all employee data (job title, department, manager, location, contact information, etc) and owns the hire and termination processes that affect the account management lifecycle.
Identity Management relies on triggers in the enterprise ERP system to create, modify, disable, and delete accounts in all connected systems according to well-defined business rules. Thus, an employee hire will automatically create a user identity, assign the user appropriate accounts, and rights, for their role and then turn around and remove that identity and delete accounts when the employee leaves. Clearly, there is a lot more complexity involved here than simply slamming in a new application and training a few users.
Doing it right the first time
A common problem with Identity Management projects is that organizations want to jump ahead to realize the benefits of IdM, without having built the foundation required to support the solution in the first place. This is tactical approach that attempts to cherry pick the high value projects, without building the fundamental components of the solution first.
One common shortcut to this end is placing a special purpose directory in the position of metadirectory. The special purpose directory is one intended to support a particular system, say your SendMail application. Its user objects, schema, namespace, and architecture are tuned to manage accounts and user data for that application, but are not designed to perform the same function across multiple systems. In the end, organizations run into issues with data quality, application integration, and scalability. They often find that the directory structures that worked well to support an application are not fit for an enterprise class solution.
“Doing it right” means having the discipline to build out your core IdM infrastructure before tackling high value initiatives like provisioning, single sign on, and automated workflows. Big Sky Associates recommends establishing an Identity Management strategy and road map and having the discipline to follow it.
Labels: Identity Management
Prioritization Applied to Requirements: Top Pitfalls
0 Comments Published by John Dillard on Wednesday, June 21, 2006 at 7:42 PM.
Recently we had the chance to observe a large IT organization undertake a requirements prioritization process related to a large-scale infrastructure procurement. As most CIOs know, large organizations' spending on infrastructure can account for an enormous portion of the budget, so it's critical to get the decisionmaking process right. Failure to do so can mean half-baked, underfunded projects, spending out of line with corporate priorities, or configuration issues across the enterprise.
We jotted down some of the do's and don'ts from watching this organization work, and compared them to some of my previous client experience with CIOs. The result, a top 10 list of pitfalls in the requirements prioritization process, is listed below for your reading pleasure. What's notable about this list is it doesn't really have much to do with requirements; conversely, it has everything to do with the prioritization process and how the decisions are made.
Top 10 Pitfalls in Prioritizing infrastructure Procurement Requirements
1. The CIO doesn't have authority, or even visibility, into requirements for both infrastructure and applications
2. The criteria for requirements and the prioritization of requirements are done at the same time, allowing the group to change the rules midstream
3. Criteria overlap, degrading the integrity of the prioritization model
4. Criteria don't cover the full range of preferences or characteristics required to evaluate alternatives
5. Choices are made on the basis of perception or gut feeling rather than with real, verified data on cost and performance
6. A clear, coherent process for decisionmaking isn't established at the outset
7. Requirements are ambiguous, ill-defined, or otherwise difficult to understand quickly
8. The decisionmaking group is a cabal of like-minded leaders from the same organization with the same agenda, also known as an ivory tower
9. Priorities are set in the absence of a clear and coherent vision for the enterprise architecture
10. Requirements are funded based on an arbitrary cutoff line, rather than on the basis of comparative analysis of different portfolios or groups of requirements
Those are the 10 that jumped out at me; there are far more. In future posts we'll write more on the implications of some of these pitfalls, and more on the intricacies of requirements themselves.
We jotted down some of the do's and don'ts from watching this organization work, and compared them to some of my previous client experience with CIOs. The result, a top 10 list of pitfalls in the requirements prioritization process, is listed below for your reading pleasure. What's notable about this list is it doesn't really have much to do with requirements; conversely, it has everything to do with the prioritization process and how the decisions are made.
Top 10 Pitfalls in Prioritizing infrastructure Procurement Requirements
1. The CIO doesn't have authority, or even visibility, into requirements for both infrastructure and applications
2. The criteria for requirements and the prioritization of requirements are done at the same time, allowing the group to change the rules midstream
3. Criteria overlap, degrading the integrity of the prioritization model
4. Criteria don't cover the full range of preferences or characteristics required to evaluate alternatives
5. Choices are made on the basis of perception or gut feeling rather than with real, verified data on cost and performance
6. A clear, coherent process for decisionmaking isn't established at the outset
7. Requirements are ambiguous, ill-defined, or otherwise difficult to understand quickly
8. The decisionmaking group is a cabal of like-minded leaders from the same organization with the same agenda, also known as an ivory tower
9. Priorities are set in the absence of a clear and coherent vision for the enterprise architecture
10. Requirements are funded based on an arbitrary cutoff line, rather than on the basis of comparative analysis of different portfolios or groups of requirements
Those are the 10 that jumped out at me; there are far more. In future posts we'll write more on the implications of some of these pitfalls, and more on the intricacies of requirements themselves.
Welcome to Big Sky Thinking
0 Comments Published by John Dillard on Tuesday, June 06, 2006 at 5:11 PM.
Welcome to the launch of Big Sky Thinking, where Big Sky Associates will post its most current ideas related to helping organizations improve technology, strategy, and operations decision making. We thought it important to introduce Big Sky in this first post to explain what we do and how that helps our clients.
In short, Big Sky Associates, Inc. is a management consultancy with a singular focus: to help organizations make better choices about strategy, budgets, and systems – in short timeframes.
The firm was founded in reaction to the founders' observation that organizations faced with more and more resource constraints have few effective methods for improving practical decision-making that are grounded in theory and tailored to their industry. Furthermore, those organizations face pressure from shareholders and stakeholders to reduce timeframes in which critical decisions are made. Add increasing enforcement of compliance with regulations and directives--such as Sarbanes-Oxley and the Performance Assessment and Rating Tool (PART)--and organizations find themselves making critical choices without tools to achieve the appropriate level of fidelity and timeliness.
Big Sky isn't in the business of making decisions for our clients. We help clients accelerate and optimize decision making by examining the mechanisms by which decisions are made and identifying the fastest path to improvement. In our work with clients we have observed several areas of critical importance:
In short, Big Sky Associates, Inc. is a management consultancy with a singular focus: to help organizations make better choices about strategy, budgets, and systems – in short timeframes.
The firm was founded in reaction to the founders' observation that organizations faced with more and more resource constraints have few effective methods for improving practical decision-making that are grounded in theory and tailored to their industry. Furthermore, those organizations face pressure from shareholders and stakeholders to reduce timeframes in which critical decisions are made. Add increasing enforcement of compliance with regulations and directives--such as Sarbanes-Oxley and the Performance Assessment and Rating Tool (PART)--and organizations find themselves making critical choices without tools to achieve the appropriate level of fidelity and timeliness.
Big Sky isn't in the business of making decisions for our clients. We help clients accelerate and optimize decision making by examining the mechanisms by which decisions are made and identifying the fastest path to improvement. In our work with clients we have observed several areas of critical importance:
- Budget and financial decisionmaking, – such as financial analysis and program plans
- Technology selection and requirements analaysis -- with depth in solution requirements and identity management
- Sourcing and acquisition – such as vendor selection and material or service acquisition
- Bigger bang for the buck – higher success rate for choices made using sound decision and optimization theory, and higher performance per dollar spent
- Faster “time to market” – shorter duration from dilemma to action
- Reduction in decision-related flaws – reduced waste from systemic decision making errors
- Decisions that stick – more defensible decisions that stand up to stakeholder and shareholder scrutiny
- Decisionmaker Consensus –participants buy into and act on decisions after meetings are over
