Have you every been at a baseball game and watched two outfielders collide while trying to catch the ball? This course is designed to help you and your organization avoid such collisions. Especially when it comes to Azure.
Using a structured process to define clear Azure roles and responsibilities results in a secure system that ensures people, applications and networks work exactly how they should; no less or more. This course, Identifying Roles and Responsibilities in Microsoft Azure, is designed to help you and your organization avoid such collisions, especially when it comes to Azure. First, you'll define what RACI (Responsible, Accountable, Consulted, and Informed) is and what it is used for. Next, you'll discover a process to ensure everyone is on the same page in your roles structure. Then, you'll walk through an example of how to apply the process using The Azure RBAC structure. Last, you'll touch on Azure custom roles and how to build them. By the end of this course, you’ll know all the basics that will allow you and your team to begin leveraging RACI for your Azure implementation.
Jason is an IT program manager who started his career in software engineering. Eventually, he decided that his passion was the people-and-process side of the development life cycle. He has served as a business analyst and project manager. Jason received a PMP in 2007 and a CSM in 2014.
Course Overview Hi everyone. My name is Jason Edelman, and welcome to my course, Identifying Roles and Responsibilities in Microsoft Azure. I'm an independent author and coach with over 20 years of varied IT experience starting my career as a software engineer and then going all the way through to serve as an executive. Have you ever been at a baseball game and watched two outfielders collide while trying to catch the ball? Both are well intentioned, but if they played their positions, the collision probably would never have happened. This course is designed to help you and your organization avoid such collisions, especially when it comes to Azure. Some of the major topics we'll cover include defining what a RACI is and what it's used for, explaining a process to ensure everyone is on the same page. I'll walk you through an example of how to apply the process using the Azure RBAC structure. I'll touch on azure custom roles and how to build them. By the end of this course, you'll know all the basics that will allow you and your team to begin leveraging RACI for your Azure implementation. Before beginning this course, you should be familiar with the different roles and responsibilities found within an IT organization. I hope you'll join me on this journey to learn RACI with the Identifying Roles and Responsibilities in Microsoft Azure course at Pluralsight.
Understanding RACI Have you ever seen two baseball players dive to catch the same ball only to collide into one another watching the ball bounce to the ground? The same thing can happen to you and your team, in your department, or in the systems you manage. Hello, my name is Jason Edelman, and welcome to my course, Identifying Roles and Responsibilities in Microsoft Azure. Using a structured process to define clear access roles and responsibilities will result in implementing a secure system that ensures people, applications, and networks are able to work exactly how they are supposed to work and no less or more. So if you want to learn a process for how to implement a RACI for your Azure implementation, then this is the course for you. While we'll be touching on high-level concepts of Azure, this is a beginner course and will not be getting into the detailed implementation steps. Here, we will be focused only on providing the most effective way to plan your Azure role implementation. Here is what we'll be covering. Understanding RACI, its purpose, anatomy, and variations. We'll also be looking at a template and a process that you can use as a basis for your implementation. After this introduction, we'll be walking through a fictional Azure implementation using the planning process I explained. Let's get started.
Define and Document Your Azure RACI – Responsible Parties Defining responsible parties. Let's say for sake of argument that there exists a software engineer who has developed a small application in his own instance of Azure. He showed it to a CTO and CEO and they love it, and they want to bring it to market. Apart from all the legal and monetary consequences that could be involved, the engineer agrees. Obviously they cannot keep this in his own personal instance of Azure any longer. It has to be brought into the corporate instance. And there are other infrastructure complexities to work through in order to bring it online and to market in a stable environment. So what now? Let's take a look at how the engineer set this up in Azure. First, he's got his own personal free subscription plan. Then he's developed his own resource group. And then underneath that, he's got his different resources, his SQL database, his application, server, storage, DNS mapping, his user accounts, all of that good stuff.
Define and Document Your Azure RACI – Accountable Parties Defining accountable parties. In our example, our software engineer pulled together all the leads from each IT team. First, they discussed responsible parties and made sure that the appropriate groups were all made responsible for their tasks. Next, they discussed who is accountable for the tasks. Accountable, if you recall, has the final authority or accountability for the task's completion. So after continued discussions, the following roles needed to be added to the matrix. Software engineering manager. The software engineering manager oversees all of the activities for multiple engineering teams. He performs the code reviews, develops standards, manages human resources, and is accountable for all the delivery of high quality products. Infrastructure manager. The infrastructure manager oversees the cloud engineers and the networking staff. She works closely with the other managers, especially the security manager. She is accountable for all the environmental failures, uptime, and connectivity incidence. Security manager. Finally, our security manager is accountable for ensuring that all the environments are hardened, that permissions are appropriate, and they also are accountable for setting security standards and for many of the various external audit and compliance issues and tasks.
Define and Document Your Azure RACI – Consulted Parties Defining consulted parties. The previous example identified all the manager level and contributor level people that were to be held accountable for all the work assigned. The next role the group discusses is the consulted role. Consulted parties act as a consultant to the task. After continued discussions, the following role assignments are added to the matrix. Lead software architect. The lead software architect plays consultant to the software engineers and their manager. Without this oversight and guidance, the software engineers may implement different frameworks or technologies that are noncompliant. Product manager. The product manager is the roadmap person. They need to stay informed on progress of the latest releases and consult on what will be coming up next. Chief technology officer. The chief technology officer may be driving the whole ship, but he is pulled in so many directions that once he sets the path for others to follow, he's onto the next thing. So he needs to remain informed on how prior guidance is being implemented, but he also still needs to consult on certain things actively.
Define and Document Your Azure RACI – Informed Parties Defining informed parties. The previous example identified all of the individuals that acted like consultants to specific tasks. The final role they discussed is the informed role. The informed role members are those that need to know the task exists, why it's being done, and when it's completed, or sometimes when a decision has to be made. After discussions, it was determined that a number of others needed to be at least informed of tasks that are concerning them indirectly. Here's what it looks like. All of the I's in the cells represent the informed parties. In regards to RBAC, those individuals probably do not need access to all the Azure resources. They can get informed from others. You can see that the biggest person to keep informed is the CTO. At the end of the day, he is accountable for all. But it's a little redundant to put a task on the RACI to indicate that. Now that the matrix is complete, let's do a quick gut check to validate that it follows the rules we discussed earlier. Does any one role have too much responsibility? I would say that there's a good balance of responsibilities. Where are there no R's? The architect role has no responsible or accountable tasks. So the team will need to go back and define that role in greater detail. The infrastructure manager is accountable for a lot. Perhaps some of his accountabilities, like user provisioning, should fall on another group. There are no empty boxes, so I think that apart from perhaps revisiting the architect role and the infrastructure role, things are good. The team agreed to iterate on the RACI and make sure that all ambiguities are clarified. After all, the whole point of a RACI is to ensure that everyone is performing their assigned duties appropriately.