When organizations start or plan to start a new IAM initiative, one of the first steps they take is some form of requirements gathering. The idea is that the requirements represent the functional and nonfunctional (IAM) needs of an organization. Then, typically through some form of procurement, the organization attempts find a solution/service/product(s) that best aligns with those requirements.
However, determining which solution best aligns with these set requirements is tricky because it can be difficult to determine which product features, functions, and capabilities come out of the box, are obtained through configuration, or require some level of customization to achieve. Often, this is a very nuanced conversation that requires a substantial level of expertise to effectively discuss.
The general rule of thumb is that you want to find a (single) solution that has all of the required functionality built into the product, therefore, requiring minimal configuration. Organizations typically want to avoid anything custom because this tends to be expensive to build, maintain, and support. Additionally, custom solutions are generally not sustainable over long periods of time.
Out of the Box
When we refer to out of the box, we are referring to any built-in feature or functionality that does not require configuration or modification to work as needed once an IAM solution is installed.
We will use a simple concept of self-service password reset (SSPR) throughout this article to illustrate the key points. This SSPR function allows a user to reset their own password if they want to change it or just forgot it (versus having to call a help desk and have someone else do it). It is a very common requirement for any IAM solution to have this capability.
So, if you were to look at ten different IAM solutions, there is a good chance almost every one of them will say in their marketing and product documentation that SSPR is a feature. Great! We have verified that all the potential solutions have a feature that is on our requirements list. At this point, many might move on to the next requirement. Not so fast….out of the box is just one part of requirement analysis; specification definitions and the mileage will vary for each solution.
While a particular solution may claim to have an SSPR function, there is actually more to it than that. Other questions one might ask are:
- What does the SSPR process look and feel like for the end user?
- Is the password reset performed via email, text message, or some other format?
- What information is required or is a user prompted for when doing an SSPR?
Configuration
Just because a solutions says they have a capability does not mean all the specific functions that an organization may need are actually there. Many times, these claims are more marketing hype than product reality. Most product functions, like SSPR, are typically paired with some level of required configuration. In the case of SSPR, a typical solution would have configurations such as:
- Enable/disable SSPR
- Forgot password reset methods to use either email, text, OR something else
- How many times a person can reset their password within a certain period of time
- What information, such as username, date of birth, etc., is required to prove that you are resetting your password and not a password for someone else
These are some common examples of potential configurations that could accompany an SSPR function in an IAM product. These configuration options are typically available to administrators of the IAM solution, but some might also be available for the end users to decide. This part of the requirement analysis is critical, but often skipped. Skipping these details during the evaluation typically leads to misalignment of requirements and solutions and ultimately, to unsatisfied customers and users.
Customization
A common scenario is that an organization just does the high-level, cursory review of a product's actual capabilities. Then, part-way through the implementation, they discover the product may not have all the functions or features they really needed. Discovering this requirements gap is usually what triggers a project to transition from configuration to customization.
Customization is where a product provider (or the customer) must develop new code or create links between multiple systems to achieve required or desired functionality. Basically, instead of a checkbox, code must be written.
Continuing our example of SSPR, perhaps the organization wants to offer its users the capability to decide if they want to use email or text for their password reset, but the product only supports one of the two AND only allows the administrator to make that configuration, not the users. Well, by this point in the IAM project, the system is half built. It is too late to simply turn around. Now, the customer must either do without these capabilities OR pay for customization of the project to incorporate these requirements in some manner.
Start with the Problem
It always surprises me is how many organizations end up in this predicament. So, who is at fault? One argument might be that the solution provider was not forthcoming when the initial discussions were happening around requirements and capabilities. Or, perhaps, the organization holds some of the responsibility because they did not do their due diligence when evaluating the solution OR did not even think or know to ask those types of questions to begin with (i.e. requirements).
There are additional factors that can lead to this misalignment as well. Recall, the goal is to find a solution or product that best aligns to the requirements. Well, where do these requirements come from? A common mistake when starting IAM projects is to turn the requirements gathering effort into a features and functions wishlist, instead of deriving the requirements from an actual problem or challenge that needs to be solved. When you only look at features and functions, there is a tendency not to look at the details—those additional questions you need to ask. When you start with the problem that needs to be solved, then those important questions you need to ask will become more apparent.
Finding the Right Solution
Organizations should take the time to thoroughly analyze the problems and challenges they are having and to derive appropriate requirements and specifications, and then, find a solution that best aligns to those points. You should look for a solution that meets all your needs and has the capability to adapt to changes over time through simple configurations changes, not customizations.
On the other hand, you want to avoid solutions that are overkill, with more features and capabilities than you really need. This is a mistake I see made frequently because organizations don’t understand the challenges they are having, so they shoot for the moon and get a solution that has everything under the sun. The reasoning here being: If you get a solution that does everything, it will be able to meet any need or requirement your organization will ever have.
However, this approach is actually extremely counter-productive because (1) you will pay more money for this type of solution because it is everything to everybody, with a seemingly unlimited set of features and configurations. However, (2) the organization will only use a small fraction of those functions and will have to spend even more money customizing it to turn off or hide those unneeded features. How about that? You pay lots of money for a product and then have to pay even more to turn off everything for which you just paid.
---
A little bit of upfront effort to understand the challenges your organization is facing goes a long way when starting a new IAM initiative. Taking time to write down solution requirements that align with the actual challenges your organization is facing is a crucial step in the process. Following these steps will help you find a solution with the functions, features, and capabilities you need directly out of the box and with minimal configurations required.
Comments