Brian Weigel, IAM Consultant, SecureITsource, Inc.
Welcome to the first in a new series of articles focusing on Agile development in Identity and Access Management programs! These will be spread out over several weeks to encourage readers to review, contemplate, and discuss the concepts and implications, and to provide ample time for Q&A before moving on to a new talking point. All feedback is welcome and encouraged!
I know many readers will come from a software development, implementation, and/or management background, and the word ‘program’ in the paragraph above probably stuck out to you. I would like to make a point of clarification before we dive into how Agile can help you succeed. When I use the term ‘program’, I am referring to the holistic IAM implementation, management, and support process – regardless of the chosen ‘solution’ (read ‘software’). Also, while the primary focus of these articles will be on IAM, the same principles apply to PAM (Privileged Access Management) and DAG (Data Access Governance). As we dive deeper into how Agile can help you succeed, I will note how certain concepts can be applied to PAM and DAG as well.
Far too often, IAM is viewed as a ‘project’ with the bulk of emphasis on the initial development, customization, and deployment phases, and focus tends to begin drifting away from IAM once the initial implementation phase begins to wind down. This is often compounded when the initial implementation is facilitated by a solution vendor/partner and the engagement is ending, and on-staff resources are either unfamiliar with the solution, allocated to other projects, or are being onboarded late in the game.
Businesses evolve, and a ‘once-and-done’ approach to IAM is guaranteed to leave you in a tight spot somewhere down the road when you need to adapt your solution to meet new requirements. Even if you are going to bring in outside help for your implementation, it is always best to begin preparing your ongoing support and maintenance staff as early as possible, and encourage them to integrate with the solution partner to learn how your solution is being built so they can carry the torch afterwards. This is the path to true success for an IAM/PAM/DAG program, and we encourage all our customers, clients, and associates to embrace this mentality.
Let’s take a moment to reflect on what it means to be ‘agile’. Too many times I’ve heard people say, “We are going to do Agile because studies show it’s more successful than waterfall”. ‘Agile’ is an adjective, describing something that you are. A more appropriate statement would be “As a company, we will become agile because our business is always evolving so that we can maintain (and increase) our competitive edge in the market and ensure that what is delivered meets our needs”. That statement is also an example of a user story, but more on that in another article.
To become agile requires a mentality shift, and is founded on the principles of “inspect, adapt, and execute”. In the simplest form of the process, the development team builds some functionality requested by their stakeholders (usually over a period of a week or two), demonstrates the functionality that they believe is ready to be delivered, and the stakeholder either accepts it as-is, or notes what changes need to be made, at which point the development team goes back and the whole cycle begins again.
To wrap up this first article, you may be asking, “What makes Agile so great for something like an IAM development/implementation project compared to our traditional waterfall approach?” Most IAM deployments take a significant amount of time and effort (1.5 to 2+ years is quite common for a large environment), and have a lot of complexities involved (legacy systems, diverse environment, custom system integrations, etc.). Even with years of planning and requirements-gathering and documentation by the best and brightest, something will always either be missed, or made out-of-date at some point after the planning phase has ended and the requirements are ‘finalized’, leaving a painful gap that often causes a lot of conflict between the business that sets the requirements and the development team working to implement the solution. Business stakeholders often go several months without seeing any of what is being built, at which point making corrections becomes a far more complicated than if it was caught early. Finally, trying to detail everything in advance often makes the solution far more complicated than what would be delivered with a short-cycle ‘inspect and adapt’ approach.“No plan of operations extends with any certainty beyond the first contact.” – Helmuth von Moltke
SecureITsource is an authorized reseller and professional services partner with the industry’s leading Identity & Access Management solution providers. Our team of experienced consultants help our clients to achieve their IAM goals by providing strategy, design, and engineering expertise.
Visit our website at www.secureitsource.com