The Stages of Identity

Recently I’ve been thinking about what happens to an identity through its life cycle and how the identity data is treated during this process.  I think you will also see that the Enterprise itself has differing methods of dealing with it as well. I am considering this to be the beginning of a framework and nomenclature that one can use for expressing how people relate to their Identity data on a number of different levels. I think we can pretty much consider this to be a “work in progress,” and I would greatly appreciate feedback.

So why do we need this, anyway? I have observed that organizations, consulting groups, and other industry experts relate to Identity based information. It seems that we all have our own set of assumptions about what is supposed to happen to this information based on our roles and responsibilities and that such a framework will help to organize our thinking a little better.

First off we have what I refer to as the Pre-Identity. During this time the data that will become the identity is in its most undefined form. Data in this stage might sit in a number of different silos or systems before moving on but is mostly used by Employment and HCM systems. Typically this data has some form in that it can identify and maybe even describe an individual in terms of the Enterprise, but it does not say anything about what it can actually do.  At this stage there are no entitlements that are associated with the user. The primary relationships held by this data are mostly legal ones as this data is used to connect with government and other systems to prove data on a legal / governmental level, such as the IRS, Department of Motor Vehicles, etc.

Once we have connected the data and accepted it into the Enterprise, the Identity information moves out of Pre-Identity systems into what I refer to as Dynamic Identity. This is the phase of Identity Management that most of us work with full time.  We will analyze this data, transform, populate (and de-populate) it in our Enterprise systems. This is also the time that we will grant, modify and revoke entitlements and apply that extra “dimension” that did not exist in the Pre-Identity stage. As the relationship between people, their Enterprise Identity and their organization(s) change, so will the Dynamic Identity. Systems and Processes will constantly be changing based on the need for access based on geography, roles, titles, responsibilities and other enterprise requirements.

Happening mostly at the same time as Dynamic Identity is that of Interrogative Identity. This stage of Identity encompasses some of the latest trends in the field of Identity Management. As there is an increasing need to clarify, document and ultimately define what an Identity has access to and ensure that the Identity is compliant with internal enterprise rules (governance) and governmental rules (compliance) it is essential that there is a defined set of processes that enable this to occur. There are now several sets of guidance on these practices established by governments and standards bodies and a growing set of application vendors to help navigate their processes.

As another dimension of Interrogative Identity, there is the constant need by the Enterprise to understand its own data. Access to data through Enterprise Systems and linking the elements of Pre-, Dynamic and even Interrogative Identities is increasingly being managed by Business Intelligence (BI) systems.  Our understanding of how the Identity and Enterprise are connected is being enhanced as BI is extended into Identity models. This trend will only continue to grow; however its management through will need to be maintained and monitored by Dynamic and Interrogative systems to ensure that Identity and Access data is properly protected.

Finally, we must define what happens when an Identity is no longer associated with the Enterprise. The Post Identity phase is one that is often overlooked, and is the cause of many exploits and Identity Management related crises. Ensuring that there are ways to properly separate the user from the Enterprise systems while maintaining their existence for ongoing Interrogative Identity practices is required properly complete Dynamic Identity operations.

Throughout this article I have made references to “the Identity” without going into much detail.  This is done this on purpose so that there are no preconceptions as to what can be managed by this model. Any type of Enterprise object could be managed in this framework, whether it is people, groups, roles, privileges or other objects such as systems, phones and other hardware, and the relationships therein.

I have also been somewhat vague about what constitutes the Enterprise.  For far too long, the field of Identity Management has been confined to the Corporate Enterprise. However with ongoing initiatives to “Cloud” and “Service” based systems, there is a greater need to manage and monitor these relationships as one would in a Corporation or Government system. Our increasing reliance on systems such as Google, Facebook, LinkedIn, Yahoo!, etc. to store our data and provide next generation service such as Federated access makes this all the more essential.

This does not mean that non-cloud methods and repositories do not benefit from this type of organization. These relationships are just as important when considering ERP, LDAP and other "classic" Enterprise systems as I have referenced earlier in this article.  The organization of this data is still among the leading determinants in the choice of both ERP and Identity Management systems. It is my hope that in defining and expanding this framework in terms of Pre-, Dynamic, Interrogative and Post Identity stages (PDIP) that we can find a way to address all types of Identities in all possible systems.

Learning from your mistakes

I love making mistakes.  It's probably the best teacher in this world of Identity Management. In honor of that (and before the technical content, some thoughts on making mistakes:

Never say, "oops."  Always say, "Ah, interesting."  ~Author Unknown

It's always helpful to learn from your mistakes because then your mistakes seem worthwhile. ~Garry Marshall, 'Wake Me When It's Funny'

Lost some time on my current project while NetWeaver needed to be reinstalled, no big deal since I could prototype a few things on my local environment and try and prepare for some of the challenges we knew would be coming up. Nevertheless, as soon as the server was ready, I was eager to get going.


Reconfiguring NetWeaver went through without a snag.  We even were able to observe a few things that were done differently the rebuild and documented some best practices. When things are going this well, I should know better and start concentrating on what I'm missing. There's just too many things going on for things to be going this smoothly.


We configured the JDBC Driver and then the JDBC Datasource (IDM_DataSource) which went through without a problem (and part what caused us grief before)  My "Spidey Sense" should have been going off like crazy now.


We then went in and configured the Roles and a test user.  Then we setup that same user in the Identity Store via the MMC console. Now it was time for the big test, loading the Web UI, which came up with no errors (We were also getting Access denied, service down messages from the Web UI last time around). We logged in, which was further than we got before, but we still had a problem.

We only saw the Monitoring tab.  I checked the assigned roles for the user and removed idm.monitoring.admin (my read/write role for monitoring), logged back in and still only saw monitoring.  How strange.

Did some thinking, did some Googling, read some slightly related SDN posts with no clear relation or answers and did some more thinking.

As I pondered the install process and the login process, it hit me! Turns out we were so excited that we skipped an essential step!  We never configured the JMX layer and set the Identity Store value or the Keys.ini location. (Good thing I only tried to log in and not change any passwords!)

Loaded NetWeaver Visual Administrator, navigated to the Configuration Adapter node and found the tc~idm~jmx~app node and flipped on edit mode, made the two changes and I don't even think I needed to log in again, all my tasks came up on a Web refresh.

I made a dumb mistake and got ahead of myself.  Fortunately we got it all working without too much time lost.

So what did I get from this:

1. Always follow the documentation.  It's the best way to make sure you don't forget anything.
2. If you're having a problem, use tools like Google and SDN.  Even a "slightly related" posting can help you brainstorm.
3. Get another set of eyes to look things over. People from the BASIS team can be your best friends here.  Even if they've never heard of IDM, they probably know more NetWeaver than you.
4. When all else fails, go back to #1 and RTFM, most likely you misread something!

One of the interesting things about mistakes is that a lot of people (including famous ones) make them all the time. So in honor of that, here's some more quotes:

Do not fear mistakes. You will know failure. Continue to reach out. ~Benjamin Franklin 

I've learned that mistakes can often be as good a teacher as success.  ~Jack Welch 

Another Blogger comes up to Bat

I was quite happy to discover a new person blogging on SAP's NetWeaver Identity Management. Ian Daniel, of Adventures in SAP IdM. Of course in Ian's case it's a Cricket Bat as he works and lives in the United Kingdom.

Ian seems to be the first of a new breed of IdM consultants making the change from traditional SAP consulting to Identity Management.  From reading the first few posts, it seems clear that he has both theoretical and field experience, which is always a welcome combination. I'm looking forward to seeing what he has to say in the coming months, and I think you will too.

Look for posts on his blog and on SAP SDN.

Welcome to the team, Ian!

Some quick reads in SAP IDM and IdM in general.

Reporting, Metrics, Audit, whatever you want to call it, relies on being able to extract information from your identity management systems.  This article is a brief discussion on the topic.  I was fortunate to meet one of the authors, Gerlinde, during TechEd last year.

It's also nice to know our market is growing!

Dispatcher Tips

It’s one thing to build a system in a sandbox or lab environment and a completely different thing to run that system in a production environment. There are a number of things that system designers and architects need to consider. Some of these considerations are fairly obvious, such as RAM, processor, network configuration, whether or not to virtualize, etc.

However one of the things that sometimes gets forgotten in a NetWeaver Identity Management solution is the use and configuration of dispatchers. These seemingly small pieces of the configuration are responsible for a great deal of the operation of NW IDM, as they actually process and execute the provisioning jobs in the workflow.

There are a couple of basic rules of thumb that should be considered when planning for deploying dispatchers in a productive environment.

• There should only be one dispatcher per host. If anyone has any data on this, I’d love to see it. In an ideal world, it would be one dispatcher per physical host. I have not done any testing in virtualized environments, but I don’t see that as being a huge issue.
• Plan on one dispatcher per about every 25,000 users.
• If you have specific types of tasks and workflows that require special access, create a specialized dispatcher that supports them. Specific examples would include password management and deprovisioning.

It’s also important to consider that there are several options for tuning the dispatchers, which we will discuss in a future post.

Conflicting Views on IdM Acceptance

Within a span of a couple of days I saw an interesting contradiction regarding the adoption rate of Identity related technologies, particularly in Europe. This contradiction came through a couple of articles I found on Identity Management through my trusty Google Search agent.

The first article, basically states that adoption rates have not been as high as they should be since everyone is acknowledging their importance. Additionally the prevalence of cloud technology brings about a new wrinkle in managing Identity which has yet to be properly addressed and might be a way of pushing acceptance of IdM. It also states that the inherent complexity in IdM creates additional acceptance and execution barriers.

The second article, takes a more positive approach to the acceptance of IdM technologies. Particularly when considering Privileged User Management.

Interestingly enough, both articles referenced the same Forrester report, Identity and access management adoption in Europe.

What should we take away from these article?

1. While both articles mentioned that the Cloud could be a great IdM enabler, there was not much mentioned in the way of Architecture models by which this could be addressed. Guess you have to engage Forrester for that information.
2. Looking for IT and IS goals such as Privileged User Management can be a great way to gain additional acceptance for an IdM project.
3. Another issue that the articles do not mention is that acceptance can be promoted by leveraging established ERP application. Both Oracle and SAP now have Identity Management Systems that have specific functionality to provision in their respective internal landscapes as well as to the Enterprise in general. IBM also features similar tools for their infrastructure. Seems to me that along with Privileged User Management as discussed above, this could be another tool to gain IdM project acceptance (and more importantly, budget dollars) Quite a few project proposals I've come across lately are adopting this methodology.

Finally, I'd like to comment on the complexity issue. IdM is made complex when organizations do not execute from an agreed upon game plan. This plan does not need to be all that complex, and briefly consists of the following:

• Understanding the Identity related needs of the organization
• Prioritizing those needs based on potential return which could be based on, time savings, monetary return (ROI through reduced Help Desk calls) or consolidation of workflow, portals and other IT infrastructure, and ability / time needed to design and develop the parts of the solution
• Executing a Project Plan based on these criteria

Like I said it does not need to be complex, but does require a certain amount of Project Management and, perhaps more importantly, buy in from the various project sponsors. Avoiding complexity in determining objectives, results in lower complexity of the finished product.

Managed Services Models for IdM: Slomin Shield or Roto-rooter?

One of the issues in handling Enterprise level implementations, such as Identity Management is what to do when the project is completed? The answer to that is to make sure it’s monitored and that there is a methodology to manage the implementation.

First of all we need to make sure that all connected sources and targets are up. Normally this is not a problem for most enterprise systems since they are monitored from Enterprise Management systems such as HP Openview, CA Unicenter or Microsoft MOM. It’s essential that in addition to making sure the systems are working, we also need to make sure that the systems are all talking to each other. This specific type of monitoring cannot always be done using these standard tools.

In addition to monitoring it is also important that we can manage the implementation for troubleshooting, maintenance and enhancement. When these concepts are combined, we have a recipe for the concept of Managed Services. When I consider the way that managed services work I see two basic models, which I like to call the Slomin Shield and Roto-rooter, two companies you may or may not have heard of.

• Slomin’s is an Alarm Company that offers central service monitoring. If they detect a problem, they call, assess the situation and take appropriate action.
• Roto-rooter is a plumbing company known for their quick response to service calls.

Both organizations represent effective, but different models for providing essential services, but which one is correct for Identity Management? They both have their pluses and minuses depending on the organization’s business drivers, staffing needs and high availability requirements. Based on some of my thinking this is how these models would work for Identity Management.

• The Roto-rooter model is a reactive model. When an organization sees that something needs to be done, a call is made for support services. More often than not, there is an arrangement for providing these support services. Engagement is made on an as needed basis for dealing with enhancement and upgrade processes.
• I would characterize the Slomin’s model as a more proactive model. In this model, there would be ongoing monitoring to make sure essential servers are responsive. As soon as incidents are uncovered contact is made with corporate IT to provide information on system status and likely causes of the problem. Resolved incident details would be entered into a knowledge base to provide historical data not only on what failed, but why it failed. Furthermore there is an ongoing review of needed enhancements and comprehensive review of patchers to determine applicability.

Like I said before, I don’t know that one model is inherently better than the other. The decision to embrace a particular model depends more on the organizations’ business needs and requirements. I hope to examine the pros and cons of each model in future entries.

Promising News

Had an interesting article cross my email today from techtarget.com. It nicely dovetails with discussions I've had with many in the IdM and Security fields.

The basic fact is that businesses save money when they implement Security and Identity Management projects. The costs of one security breach, password exploit, compliance violation, etc. dwarfs the investment and maintenance of a sound enterprise security infrastructure.

I found it interesting that the experts quoted in the article specifically referenced, encryption, compliance and Identity and Access Management technologies. I would also recommend the use of SSO technologies which make it easier to enforce password policy and promote compliance.

In the war of data security, a good defense is the best offense.

The Yo-yo theory

I was talking to someone the other day about the economy and how IT and security are affected by it and I made the following observation and analogy:

Everyone knows IT spending is important and can result in real benefit to the company however, there's a tendency to use yo-yo budgeting.

When things get tough, the yo-yo is dropped as spending slows and we expect IT to run on the bottom for as long as possible, but eventually we need to catch up and snap the yo-yo back up and we catch up on technology.

Maybe the reasoning is a bit simplistic (after all I'm an IdM architect, not an economist) but I think it holds up and I'm pretty sure that this model would extend beyond IT as well. I'm wondering how much the model holds, does a slower decline mean you can stay down longer or not? Does each department have it's own yo-yo?

Where's an economist when you need one?

New School Identity Management?

I'm all for a discussion of changes in the Identity Management world, in fact I encourage them. I think it's a pretty dynamic world. As Mark Diodati mentions in his article "Changing times for identity management" (login required) There are elements of IdM that are established parts of IT infrastructure, and then there is "New School Identity Management, where he talks about Privileged account Management, AD Bridges and Virtual Directories"

All due respect to Mark, who I know has been around the IdM world for some time, but none of these elements should be considered New School and have been around for quite some time.

• Privileged Account Management - I don't know of an engagement I've worked on in the last 5 years that did not have some concern about the creation and management of both Privileged and Service accounts. If anything, because of their nature, these accounts have a greater need to be created in such a way that they are done according to mandated processes and recorded for audit and review.
• AD Bridges - While not a technology I've gotten to work with a lot I know that many a mixed UNIX/Microsoft shop consider the Vintella/Quest tools to be indispensable.
• Virtual Directories - Again, a technology that's been around for a long time. I've been working with Virtual Directory technologies since 2004, where I would commonly show customers how to map information, provide access controls and even used the Virtual Directory as a write back mechanism to supported repositories.

I can say that I'm glad these Identity Management technologies are finally getting their time in the sun. Some of these technologies have not been considered as interesting or sexy since they worked with a subset of users. I think we can all agree that there are more end users than UNIX accounts or system accounts so they should receive some more attention.

However, in the end, the design and implementation of an Identity Management solution must be holistic in nature. Regardless of one's opinion on the New School qualities of the all the technologies Mark mentions in his article, they must all be considered and planned for in the final design.

Where oh Where will MySQL go?

Well it's been just over a day since the announcement of the Oracle/Sun announcement. A lot has been said about the match, some good, some bad. Most note (as did I) that the Java and Hardware additions to Oracle are a plus and that there's a bit of overlap.

One of the most interesting elements of overlap is MySQL.

Sun and Oracle have been going tit-for-tat with acquisitions going back to Waveset/Thor a couple of years ago in the IdM space. Oracle has been doing the same thing with SAP trying to build its own version of NetWeaver and an ERP suite. Now all three companies have the same basic arsenal of products with their own specialties:

1. Sun offers both hardware/OS layers, Java, and is the Elder statesman of the IAM space
2. Oracle offers the database and is showing great momentum in the IdM and ERP spaces
3. SAP offers an ERP suite with tight integration via NetWeaver

I can't see that regulators will allow Oracle to hold onto MySQL while they hold the lion's share of the database market (44.3%) Given this I wonder what Oracle plans to do with MySQL. They could move it back to open source and set up an independent organization to manage it, but this does not seem to mesh with the Oracle Corporate Culture, which has not been historically been keen on open source.

My thinking is that SAP should try to acquire it and I wonder why they did not make a try at this before. My SQL is already the basis for MaxDB and would address a major missing piece of the SAP architecture. Being able to control both the front and back end of the SAP solution set would offer a new level of cohesion for NetWeaver and place it on a more equal footing with Oracle. However, I don't foresee a direct transaction to occur between Oracle and SAP. Look for the spin off to occur and SAP to make the acquisition as soon as they think they can get away with it.

I don't think SAP will pass on this opportunity a second time.

Other thoughts on Implementation

I liked what Ash Motiwala had to say on his blog recently on the topic of Implementation. Ash is a guy who's been around the IdM block a couple of times and what he has to say clearly proves it.

The only thing I might add to this is that a good pilot can be a lead in to Phase I. Additionally, good background work in the form of Business Analysis and Architecture design goes a long way as well.

New White Paper!

Sorry I've not posted for a while but between carpal tunnel surgery and a new White Paper on NetWeaver Identity Management have been keeping me busy.

The hand is healing nicely and the Paper has just been published. Please let me know what you think.

On a related note, I also had a brief article posted on SAP Developer Network SAP Weblogs: Identity Management.

Managing Project Communication

I've written before on the topic of how to prevent project failures, but very little about what happens as projects are failing. I was recently chatting with some colleagues about what does happen when a project begins to head south.

First of all, there always seems to be a tendency to blame the outsider. Basically this argument looks something like: "You never got the requirements right (from the customer) / you never delivered correct requirements (from the consultant)"

What does this boils down to is a failure in communication. Now the question from a risk management approach is how one keeps this communication in sync. Based on our discussion we came up with the following:

• Regular status meetings. If your executive sponsor is not at these meetings, schedule regular steering committee updates which should be just the project manager(s), architect(s) and the executive sponsor. They might not need to be weekly, but they must not be optional any of these people. Do not rely on only one side to make these reports.  Everyone must be on the same page. Make sure the sponsor is aware of the key challenges so that there are no surprises.
  
• Obtain consensus and settle the issues quickly and decisively. If there are dissenting opinions about major decisions, get the issue settled once. Don't keep circling on the issue. If there's an issue that just won't go away, get the parties in front of the executive sponsor as I've noted above. Get a final ruling and move on.
  
• Establish change controls. For some reason, no one likes to use these. There's a feeling that these are things to hide behind, rationalize additional cost or bog down the project in extra paperwork. None of these are true. All that's being done here is making sure that all project principals are aware of the change. This establishes responsibility and sets up controls for making sure that things don't get out of control. And I'd imagine that the amount of paperwork involved in a change control is minor compared to having to write the report of why the project failed. Trust me, this is not fun.
  
• Use and establish some sort of project strategy/methodology. I don't care what it is, but make sure a project plan exists and that there is structure in place. There should be a project manager who will make sure that there is a plan to complete the project, but the architect and senior engineers should make sure that there are development standards which must also include documentation!
  

These points are intended to increase communication and decrease mistrust and politics. If the project team meets regularly, tracks what they are doing and how the project changes and has a structure for managing progress and change there is less of a chance of having a post-mortem and more of a chance of documenting the best practices that were done right!

 

SELECTing from the Identity Store

Now I don't know about you, but I've always had some issues with looking up entries in the NetWeaver Identity Management Identity Store. I know there are built in scripting functions like uIS_Get, uIS_GetValue, uIS_sGet, uIS_sGetValue, etc, but they've just never worked well for me. So to compensate, I've developed my own methodology for searching and retrieving items from the Identity Store.

The basic use case is this: The Identity Management solution needs to do a look up between an incoming data feed and the Identity store. The basic idea is that if the value from the feed and the value from the Identity Store match then the entries match and updating/provisioning can proceed as directed by workflow. I'm sure you can imagine other use cases, looking up managers, phone numbers, and other frequently used attributes.

The feed processing job will use a script to evaluate the match. Most likely it will pass MSKEYVALUE but could also use some other unique attribute in the feed.

The first thing that is needed is to determine the MSKEY, if any, for the entry to be worked with. To this end, I created the following query which will be implemented by NW IDM's uSelect function, which can be used in a Provisioning Job or Reconciliation task. Following best practices for NetWeaver Identity Manager, I am using the JAVA engine and therefore JavaScript in this example.

//Create an uppercase version of Par for checking against the SEARCHVALUE
uPar = Par.toUpperCase();

MSKEYQuery = "select mskey from mxiv_sentries where (searchvalue = '" + uPar + "')";
MSKEYResult = UserFunc.uSelect(MSKEYQuery);

You'll notice one of the first things we need to do is make sure we access the searchvalue correctly. Elements in this column always have their text elements stored in Uppercase, so we need to make sure that for the purposes of searching, we have an uppercase value handy. The results of this query are stored in a variable called MSKEYResult. Now that this information is available, we can now search for needed values related to this entry.

EmployeeNumQuery = "select avalue from mxiv_sentries where (mskey=" + MSKEYResult + ") and (AttrName='HR_EMPNUM)";
EmployeeNumResult = UserFunc.uSelect(EmployeeNumQuery );

With this query I can now look for a specific attribute value for a specific user and store it in a variable. At this point we should plan on returning a more nicely formatted version of the attribute so we will return aValue rather than SearchValue which is the value for the attribute as it entered into and subsequently processed by NW IDM for use in screen output, reports, emails, etc. In this example we are returning the user's Employee number.

This process might also include another query to do a count of returned Employee Numbers to protect against potential "dirty data" entries (multiple identities for the user or to many users with the same name.) If this scenario occurs more detailed searching, involving more attributes might be needed.

Note: I don't necessarily claim that this is the best or most efficient methodology for accessing this information. All I know is that it works for me and the way that I think / process information. If anyone has ideas on making this better or properly using the embedded functions listed above, I'd love to hear about it.

Why do We Bother With Server Virtualization, Anyway?

This is something that has frankly astounded me over the years...  For years vendors such as VMWare and Microsoft have been telling us about the flexibility, power and savings inherent in consolidating Servers into Virtual Machines.

For some reason, the rest of the software industry has not caught on to this and think that this is not a scalable architecture.  I'm amazed.  I don't think any of these software firms have ever looked at a manual or talked to the vendors or their customers running virtual data centers.

There's no reason production implementations cannot run on a VM.  Modern VMs are just as configurable and scalable as physical servers.  Even more so in fact, since the files can be moved from one host server to another where more resources can be allocated.  

Wake up, application vendors!  VMWare is just as good as an IBM P server in terms of configuring hosted configurations.  This is the 21st century, let's start thinking a little more "out of the (server) box"

Non technical updates

I know that I've been spending a lot of time on NetWeaver Identity Center Issues.  Hope it's been of some use to everyone out there.  I'd like to take a few moments and just comment on some things I've been hearing lately.

First of all there's the whole LifeLock deal.  Honestly, most of my initial thoughts were unprintable and more eloquently stated in other parts of the blogosphere.  But I'll leave it at this:  Identity and Credit protection services are only part of the solution.  Basic steps in protecting your authoritative identity information should include not blabbing it to everyone you know on TV, Radio and especially the internet!  Keeping that information private should be nothing less than your first line of defense.  'Nuff said.  Moving on...

A big theme of this blog in its first life was the usefulness, properties and functioning of Virtual Directories.  So it's always with interest that I look to see what Clayton Donley over at Oracle has to say on the topic.  He's one of the few people I've seen who continue the discussion of this IdM tool.

That being said, I will get on to disagreeing with some issues in his latest blog posting:  Personal Fire Trucks and Overengineering Identity Solutions. While I whole-heartedly agree with him that many Identity projects are vastly overengineered, I disagree that caching is a factor in this. To paraphrase his story, Clayton likens the use of caching to a person buying their own fire truck in case there is a fire in the home.  

Caching as a whole makes data more ready for access and usage by users and enterprise systems connected to Identity Repositories.  Is caching a personal fire truck?  I don't think so. However, I can see that as a result of poor analysis, design and engineering, caching could be used inappropriately to bolster a failing solution.  

Caching, like all tools can be used for a multitude of purposes, much like a fire truck.  It all comes down to why you are using the cache.  Is it to supplement the solution or carry it?  Too little or too much caching results in poor information and longer, not shorter response times.   It is up to the Identity Architect to decide if the solution needs a fire extinguisher or a fire truck.  Criticizing the Architect for preparing for increased demand, latency and other design considerations is only appropriate if it is improperly used.

Most important things to ensure a successful project

As discussed earlier, a pressing concern in Identity projects concerns success and failure factors.

I believe there's a core item that both the client and the implementer can bring to the table to help ensure success.

From the Implementer, it is essential that a good business analysis effort takes place. I don't think that anyone expects that this can happen in one or even a few sessions. However, the person(s) who are doing the current/target state analysis, must ask probing questions and follow up on them. It's important that the BA has a complete and thorough understanding of what the customer has and what they want. This can be a delicate process as the BA and customer learn about each other and the processes. One of the BA's best tools in this effort is to make sure they have a good process to work with. Templates, flow charts and other tools can create efficiencies in this process.

From the client side, preparation is the key. Having documentation on current processes and flows is most helpful to make sure that the project team succeeds in delivering the correct and complete product. Now we all know that not all of this information will be available when needed, but having the SMEs on call and tracking gap items helps to remediate this. Strong client side PMs and executive sponsors are also critical in keeping this an efficient process.

Ultimately it is the synergy that is created by the client and implementation teams that brings out the best results. With both sides working together the greatest progress is made and the best results are to be had.