Home / IT & Computer Science / Cyber Security / Cyber Security Foundations: Reinforcing Identity and Access Management / Resource Implications, User Acceptance, and Migration
Resource Implications, User Acceptance, and Migration
In this video, you will be introduced to resource implications, user acceptance, and migration in the IdAM implementation stage.
Are there resource implications? Again, we’ve outlined within our business case the resource plan. Do we need people, internal people? Do we need to sequester people internally to this project? If so, for how long, which people? Any external requirements? Do we need any additional hardware, any additional software? If we do need additional hardware or software, is this something we need permanently, or is this for the duration of the project? So if we’re taking on additional staff to deliver this project, then we may need additional services, but for a fixed period of time. Are we buying things on a perpetual licence with maintenance? Are we moving to a subscription model?
This goes to helping us understand the cost and the ongoing profile of the costs.
So we need to consider resource implications for the implementation, the initial implementation, the transition and migration. And bear in mind, the people that are involved at each of these stages may change, and the numbers of people involved may change. For any contingency, the business case for the resource plan, how are we justifying this, and also the disposal processes involved? If we’re adopting lots of new systems, there will be an ongoing requirement for additional resource, more than likely. Unless we’re making savings or changes in other areas, this may be additive in terms of generating a resource requirement.
User acceptance testing. When we’re looking to implement, we said that we needed firm requirements that we can objectively measure, whether or not they have been met. User acceptance testing is part of this process. This can look at load testing, making sure that the system can cope with predicted loads, and we can predict using tools, automated tools. We can assess at what point the system fails. How many logons can the system handle at any one time?
The example we gave in higher education: if we’re taking on 3,000, 4,000 new users in a day, can the system cope? And we can test to the point of failure how well the system copes so we know what the maximum load threshold is. We can use synthetic testing tools, and we can use outcome-based metrics. So instead of saying the service must respond within four seconds, we can say, the login process must complete within however many seconds. So instead of looking at a technical metric, we can actually say, from the user turning on their computer to being logged in, the process should take no longer than x number of seconds.
So these can help us generate KPIs, Key Performance Indicators, as part of the initial acceptance testing, but also to help us measure the ongoing service quality. The user acceptance testing and the initial KPIs for accepting the solution can form a baseline that we can use for ongoing performance. We can see whether the system continues to perform at the expected levels.
Migration and implementation is our next phase. We move from planning here to actually starting to move data from the existing service to the new service. It’s important that we do not disrupt live services unless this is in agreement with the business stakeholders. So we want to protect the live data and services. So when we’re testing, we shouldn’t really be using live data. We should be using dummy data. We need to schedule this appropriately, and we need to go through appropriate governance procedures with the business stakeholders to make sure that they are willing to accept any downtime that may occur. We also need to make sure that we have appropriate rollback and contingency planning in place.
What happens if we implement and it doesn’t work? How do we get back to a system that works? So what can we do? And we plan for these eventualities before we go live. So this is part of the agreed change process.
In this video, you will be introduced to resource implications, user acceptance, and migration in the IdAM implementation stage.
Resource implications
In the IdAM context, we would need to consult the business case resource plan, understand the people available, and any hardware or software needed.
User acceptance testing
User acceptance testing tests our measurable objectives and can consist of load testing and synthetic testing tools.
Migration
Here, we would move an existing service to a new service. It’s important to not disrupt live services and it’s recommended to use dummy data until the entire process is complete.
Reflect and share: What are some of the challenges and solutions you have experienced in this stage of the implementation process? Share in the comments below.
This article is from the online course:
Cyber Security Foundations: Reinforcing Identity and Access Management
Created by
This article is from the free online
Cyber Security Foundations: Reinforcing Identity and Access Management
Reach your personal and professional goals
Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.
Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.
