Technical Requirements and Considerations

Once we have our business requirements and we have translated these business requirements into functional requirements, these need to be aligned with our technical requirements. What technology do we have in place already, and can we develop and improve processes with the existing or new identity and access management capabilities systems and services? What is the technical fit of these new services within our current architecture? Do we need to acquire or do we need to develop any additional services or systems? How do we ensure that the technology stack remains congruent and aligned?

If we acquire lots of new disparate systems as part of our identity and access management system, we need to be very careful to make sure that they have a good strategic fit with our business requirements, with our functional requirements, and the existing and new technical requirements. These all have to be aligned. Conceptually, this is a very simple statement. Practically, this requires lots of work and energy.

Can we develop and improve our technology through the identity and access management implementation? Do we need to acquire or develop additional services, and how do we assure that we are aligned? Technical stakeholders, technical stakeholders could include our IT department, our IT function. Our security function to make sure that any changes to the technology fall within the correct parameters of our security requirements. We may have some external stakeholders. And again, these could be a customer, these could be suppliers, these could be vendors. We need to make sure that those are appropriately factored in.

Any directory standards and interoperability, this is a good time to ensure that we’re considering things like Active Directory, who we want to trust, who we can trust, our approach to single sign-on, and federated identity management. What is our approach? Have we defined an approach?

What kind of resilience do we need? And if we’re delivering and developing services locally, then we need to make sure that we understand the capabilities that we have at the moment and what the requirements will mean for our existing technology. This includes existing sites, our data centre, our backup data centre. And also power. I’ve seen organizations buy some great new systems, only to find out that the electrical wiring, the physical load of the new system, of the new storage platform or whatever, actually exceeds the capabilities of the environment it’s being installed to. So again, before we buy these things, we need to be factoring this kind of thinking into our decision making. We need to be reviewing this earlier.

Also, the network infrastructure, if we’re increasing load on network links, if we’re changing the way the network works, then we need to be aware of that very early on in the process. Also, virtualization, is there a standard for virtualization, and if so, how do we meet it? Should any new or existing systems be virtualized? The corporate policy or the technical strategy may be to virtualize everything. Not everything suits virtualization, arguably, so we need to decide what we have where we have it. And also, at this stage, we need to be thinking about to what extent services will be local, and to what extent services will be cloud based, and how the network infrastructure supports that mix.

So the scalability is an important requirement for any identity and access management system. We need to scope the potential for future growth. And we can use existing data through business intelligence and analytics to provide us with an insight on what organic growth has been like historically to try and predict future growth. Good design and good architecture is modular in nature to allow for that scalability so we have loosely coupled systems that can be independently replaced. So if we spend again, time architecting a solution at this stage, it can give us a much clearer method for exchanging individual components, but also for upgrading those components to meet with a change in scope.

Now, that scale may be growth, it may also be shrinking. If our business changes, if our business divests, it splits in two, how do we deal with that change? So understanding the business strategy and the potential for growth or shrinkage is important. We also want to factor in our cloud requirements, the choice of deployment model, the service model, and the cost in any migration. So are we going to use software as a service? Are we going to use platform as a service, or idea as a service, or backoffice as a service? All of these are viable. All of these have their own advantages and disadvantages.

At this stage, we need to be understanding from a technical perspective what our preference is and what our requirements are. Also, with the different models, we want to understand whether we are happy to use a public cloud deployment or whether we would prefer a private or a hybrid model. If we’re considering cloud and local solutions, and quite often, an identity and access management system will be lots of different technical aspects working together. And we look to 802.1X, where we have the wireless working with the directory service working with a RADIUS server. This is lots of different components working together to provide a solution, so we need to plan and be aware of possible integrations, possible requirements relating to integration.

Increasingly, when we talk about cloud and on-premise solutions, the integrations start to stretch between the cloud and local services, trying to join these up. And this may be linking our directory services. This may be third-party identity provision. This may be third-party single sign-on solutions. But all of these work together to coordinate and provide a technical platform, and we need to understand what our requirements are to influence that outcome. And again, we do this at design stage. For technical requirements, as well, data portability for our application data, for our cloud service data, and any standards and size. We need to start to scope what we need to support this locally in terms of storage, also in terms of cloud storage.

Before we buy anything, we need to understand how we’re going to get the data out of any existing systems and into any new systems. If we’re migrating users, if we’re provisioning users, how does that migrate? What do we need to reprovision? So these, again, are really good questions to be considering before we start the implementation process. Often, I see organizations leaving these kind of questions until midway through implementation. It’s exciting to start a new project and to start doing things. The design phase, establishing business, functional, and technical requirements, is a little bit more boring. But actually, it’s so essential, it can avoid so much pain later on in the process.