by Milan Calina, Chief Solutions Architect, First Point Global
While Agile Software Development is gaining popularity and many organisations are running at least some of their projects following some Agile methods and methodologies, when it comes to Identity & Access Management (IAM) we often see a fair bit of reluctance to approach implementation in any way other than the traditional waterfall methodology.
The reasoning we often hear from clients is: “We tried that ‘Agile thing’ and it did not work out. This is an important initiative, we want to train our staff, and we want every aspect of the system documented to enable ongoing support when your work is done.”
It’s true that IAM projects are often complex and cut across the organisation, and no one can deny that changing an organisation to start ‘doing Agile’ is not easy. But neither of these should be a reason not to be agile, not to think agile when implementing an IAM solution. It’s also important to recognise that an IAM project is an integration exercise, with very little development – less than 5% in most cases.
Doing Agile or being agile?
In simple terms, being agile is a mindset, a way of thinking and approaching work (in our case IAM implementations), whereas doing Agile is employing and following one of the Agile methods and methodologies. (There is a plethora of good articles, blogs, and books on the subject, by the way, which explain why the prerequisite for organisational agility is ‘being/thinking’ agile, not ‘doing’ Agile.)
What has this got to do with IAM implementations? Well, when it comes to major IAM implementations analysts generally advise customers to expect implementation to cost one to eight times the software cost. However, we have seen that with a combination of thinking/being agile and an understanding of what works and what doesn’t, we can implement IAM projects in much shorter timeframes, and for significantly lower costs.
Unfortunately there is no IAM-in-a-box, and one size IAM does not fit all, but experience from most of our customers – where we both ‘thought’ agile – has been that the IAM implementation spend for services/people was in a range of one half to twice the software cost. The ‘waterfall type’ projects, in comparison, are often loaded up with cumbersome processes, excessive documentation and ‘big consulting’ methodologies. Such projects typically cost 3-5 times more than our ‘lean and agile’ projects.
The scary thing is that many organisations still prefer to take the waterfall route. The ‘old school’ IT organisations still seem to be uncomfortable with not knowing, defining and agreeing everything up front. To a large extent, this seems to stem from the experience gained on large scale bespoke software development projects where even a minor change in requirements could result in significant rework – redesign, redevelopment and retesting.
On the other hand, IAM projects generally include deployment of one or more software packages. By the nature of this being COTS software, quite a lot of relevant functionality is built in and, depending on the IAM package, the implementation from a pure technology side becomes more about configuration of the package than custom development around or on top of the software. This fact – configuration not customisation – makes IAM implementations perfect candidates to be architected, designed and deployed in an iterative fashion using some ‘agile and lean’ methodology rather than a waterfall approach.
Key facets of First Point Global’s LIAM approach
When we looked at our ‘success story’ projects, we realised that the way we work and like to deliver projects was all about being agile and not necessarily doing Agile. Even before we knew of the term, we realised we were working in the spirit of what is now referred to as lean integration. Whilst we follow the spirit of The Agile Manifesto, lean integration principles are much better aligned with our work as a consultancy and a systems integrator. LIAM, or lean identity & access management is our adaptation of the lean integration methodology.
From Wikipedia, lean integration can be summarised by seven principles:
- Focus on the customer and eliminate waste
- Continuously improve
- Empower the team
- Optimise the whole
- Plan for change
- Automate processes
- Build quality in
Whilst some of the terminology used in lean integration may appear a bit harsh, e.g. ‘eliminate waste’ – none of us intentionally produce waste – when you look deeper into the intent and practice behind those principles, they make more sense. For example, this is how we employ different lean integration principles to IAM implementations:
- One of the time and effort wasters on IAM projects is ‘analysis paralysis’ – insisting on having every little thing analysed and documented up front. On the other hand our process ensures that the requirements are documented and well understood by all parties. Whether this is in the form of Use Cases, User Stories, or Test Scenarios and Test Cases (in the spirit of Test Driven Development) is secondary. After that we normally produce high-level design, which provides sufficient information for a competent technician to start configuration. The client then verifies the configuration against the requirements, and if needed we go through a few iterations of reconfiguring the IAM tool, and once signed off we produce a detailed specification of ‘as configured’ systems. This is also the right time to commence commissioning (or ‘productionisation’) of the system, including design and set-up of necessary operational support tools, processes and procedures. Of course, this is always adjusted so that ‘must have’ client requirements are met, e.g. infrastructure standards and norms.
- Whenever feasible we opt for smaller teams of cross-skilled individuals. As an example, with all respect for testers (I used to be a tester and test manager in one of my previous lives), when it comes to verifying IAM solutions the business/system analysts who wrote the requirements and were involved in all requirements clarifications and revisions are the best people to test the system.
- We try to standardise and automate different processes. This may be the initial installation or configuration of an IAM tool, or integration of systems and platforms. Nonetheless, the IAM solution needs to be looked at as part of a broader solution and the impact on affected parties and platforms needs to be taken into account. For example, when it comes to integrating with managed systems for account provisioning or identity analytics and governance, lots of customers like the idea of one interface method and approach. This is great in theory and on a whiteboard. But if the target applications and systems do not support such an interface, and a fair amount of time and effort is required to develop such interface then, if there is a functional alternative, it does not make sense to force such a rule. Similarly, forcing ‘standardisation’ of an application’s access control model and attributes often requires lots of effort in design, set-up and maintenance, and the result is a compromise. (One size does not fit all.)
Lowest cost, fastest time to value, best chance of success
We spend a lot of time advocating agile thinking and lean integration for IAM software implementation projects. Ultimately, when it comes to IAM implementation, the methodology used should come down to the software tools you employ and their capabilities, the expertise that the subject matter experts have in these tools, and the collective team’s ability to rapidly achieve the business requirements. That is what is going to give you the lowest cost, the fastest time to value, and the best chance of success.
The choice of implementation methodology shouldn’t just be about what your organisation is comfortable with. If so, you run the risk of spending a lot of time and money reinventing the wheel or, at the other extreme, an implementation process that fails to deliver, slows you down, and blows the budget. Surely, a career-limiting move for you and for me.