In many companies, management of access rights to source code repositories as well as to other tools is handled through a centralized IT organization. This means that every request for changing access rights goes through a single point whose responsibility is to act as a gatekeeper to give or withhold the rights requested.
During the past ten years of experience in solving problems in and building source code hosting tools systems within large organizations, we have pinpointed traditional - centralized - access management as one of the tasks that wastes the time of the development organization as well as time of the IT organization. In this post I'm going to present the problem in traditional access management with an example from managing permissions to version control repositories, its effects to efficiency, and how using delegated access management overcomes the problem. After reading this post you should have a clear understanding on what delegated access management is, and how it changes the picture in enterprise IT and in development organizations alike.
To begin, lets take an example of a typical use case where a new software developer enters a team and needs access to the project’s version control system. When access to the source code repository is needed, it is traditionally requested by the person in need from the IT organization. The person requires access rights from a centralized IT organization either by filing a support ticket or sending an email. The IT organization then receives the ticket, but needs to contact the requestor's project manager or supervisor to validate whether the person is actually allowed to access the mentioned source code repository. The centralized IT organization then attaches the project manager of the project to the ticket or email thread and asks whether it's ok to grant access. After receiving the "OK" signal from the project manager, access to the source code repository is finally granted to the developer.
We can visualize the aforementioned workflow with the following graph. The graph shows each of the three stakeholders (developer, project manager, centralized IT organization) and also visualizes the information flow between them.
This kind of process seems a bit cumbersome, and even redundant from time to time. Taking into account that all of the stakeholders constantly have other things on their hands as well as on their minds, the total time it takes for the developer to receive access to the code in question, is simply too long. The more often this happens, the more time is being wasted.
An alternative approach
What if we could cut out the middleman, and manage access rights more efficiently with less interference from superfluous stakeholders? By delegating the management of access rights to project managers or to the development team itself, we will simplify the workflow and make it more efficient for everyone involved.
Delegated access management means, that the one who set ups the resource, becomes its administrator. The administrator can then control who can do what with the resource. In this case, utilizing a system that supports delegated access management, anyone from the project team can grant permission to the member in need. If more strict control is needed, the project manager can also act as a gatekeeper for granting permissions. In either case, the information flow from one stakeholder to another is simplified, and we can eliminate the now obsolete centralized IT from the process. The tools needed to communicate between different stakeholders, such as email or ticketing systems also become redundant with the improved process.
The benefits are obvious, since the centralized IT organization can now spend time solving more complex problems than taking care of access rights and figuring out whether the person requesting the rights is applicable to receive them. The process now relies on the fact that decisions should be made by the nearest person possible in the hierarchy, instead of remote organization somewhere out there. The graph below shows the same use case, only now using a system utilizing delegated access management.
Comparing the two graphs above, we can see the differences in the time that the requestor spends inactive, and the total time it takes to receive the access rights. As shown, the total time can be even twice as much. Typically, it's easy to dismiss this kind of inefficiency if it happens only once or twice a year. However, based on our experience from over ten years of working with companies of various sizes, these kind of requests happen quite often. And naturally the more frequently they happen, the more time they consume within the whole development organization.
How does it work in Deveo
Deveo supports delegated access management on a project level. In Deveo the person creating a project becomes the administrator. The administrator role controls the access rights within the project scope. Thus, the creator of the project can add, remove and modify access rights of single users as well as groups. Both individual accounts and groups can come from corporate LDAP or Active Directory service, or from local Deveo user database. Deveo also supports so called hybrid model, where users and groups can come from both local user database and from the aforementioned corporate LDAP or Active Directory service.
This video shows the basic access management workflow in Deveo.
Even though this post described the access management problem only from a source code hosting point of view and covering it from a single tool perspective, similar practice is applicable literally to any tool or system in the software development ecosystem. Typically this kind of inefficiency gets hidden in the daily work, but grows larger the larger the development organization grows.
How do you handle access management to your source code hosting or to any other tool in the software development ecosystem in your organization? Are you still using the traditional centralized access management model or have you switched to a more agile delegated model? If you need help in switching the mindset from a traditional model to a delegated one, let us know. We are more than glad to be of assistance.
Seamless software development.
Code management and collaboration platform with Git, Subversion, and Mercurial.