ISACA COBIT 2019 – Bonuses

1. DevOps – the revolution in IT

Hi, welcome to a short introduction video to DevOps. DevOps is an important topic in It and I would even like to call it a revolution. I’ve been working in It since 90 99, so not quite from the punch cards, but for a while. And I have worked with a number of practices and frameworks for software development, service management, It governance and I consider DevOps a real revolution. ITIL brought us the processes, gave us service desk, SLAs and Structure COBIT brought us proper governance. And DevOps will change our infrastructure, way of working, culture and our mindset. And the change is really worth it, as I will try to convince you further regarding the content of this video, I would like to briefly introduce DevOps as a set of It practices. I have divided these practices into three areas agile, Automation and Cultural Change. At the end of our session, I will recommend literature and trainings. Let’s start by explaining what exactly DevOps is. If we simplify, we can say that DevOps is a way to speed up It. Customers no longer want to wait half a year before we deliver an application or a functionality in It. They want to delivery immediately, and ideally if we deliver it before they even think they might need such a functionality.

Based on surveys, we can say that the organization that use DeVos practices achieve 2550 times faster deploys and the employees are 2. 2 times more likely to recommend the company. They are 24 times faster to restore failures. They have 60% fewer failures in production, less unplant work and so on. So what exactly is it? How to reach these numbers? How to achieve 200 times higher release frequency? It is a set of practices and tools that fall into the three areas mentioned earlier agile, Automation and Culture change. Let’s first look at the Agile practices. When we talk about Agile within DevOps, we mean primarily the way of software development. You can deliver the software to the customer by collecting the requirements for the entire delivery, such as the Eshop, then designing It for a month, developing It and testing for three months and then putting it on production before the customer sees it and can start using it. This is a traditional, sometimes called waterfall method. The Agile way is the second one below, where you collect only some of the main requirements, process them and give them to the customer immediately.

This means, for example, that the customer gets only the main screen with a catalog and a list of goods at the beginning. But it already has some value for him, such as he sees what it will look like and he can think of other requirements that will be required based on what he sees. He can also use the catalog and list of goods as his basic evidence. In the next step, you collect further requirements and deliver them to the customer again and so on. Currently, Scrum is the most widely used agile method for software development. According to Scrum, the development team has a role called the Scrum Master, which replaces the project manager. Scrum Master doesn’t manage in the traditional sense, but rather facilitates a team of experts. He removes obstacles to teamwork, organizes team meetings and with customers. The liaison’s officer towards the customer is the product owner who manages the requirements and ensures that they are processed according to customers priorities. The original Scrum can be downloaded from Scrumgeys. org. In a DevOps organization, teams are working agile and are also cross functional.

Cross functional means that the team members have all the necessary know how to manage a service or product for the customer. This means that we have business analysts, testers programmers and administrators in the team who monitor and operate the service. Such a team then takes care of the service from its design to complete operation. DevOps team members are substitutable and although everyone specializes, they have partial knowledge of other areas of knowledge that are needed for the delivery. The picture shows the areas of knowledge that a DevOps team member should have. There are twelve areas which include just mentioned business analysis, testing, programming, architecture and design, as well as soft skills such as courage, leadership and more. It doesn’t mean that each DevOps team member is an expert in every area. He’s an expert on one of them and has an overview of the others. Please note that you can find a lot of information about this picture in the link here. DevOps Agileskills. org so I summarize the DevOps team is a cross functional and delivers end to end service to the customer from request to operation.

Sometimes we use a phrase think it, build it, tweak it. Traditional organizational structure in It is functional where we have a separate department of network administrators, database administrators, NOC supervisory department, and so on. Such organizational structure requires a lot of coordination handovers and the communication between departments might be difficult. Therefore, DevOps requires the creation of cross functional teams in order to reduce these problems. Now you might be thinking how to set up such a structure in a large organization with huge infrastructure and highly specialized teams. At the end of this session I have links to literature and training where this topic is explained. More dramatic increase in the speed of It delivers to the customer can’t be achieved without automation. So we have cross functional teams that develops agile and at the same time much of their work is automated.

Automating and eliminating manual task is crucial for DevOps and dramatic increase of speed in It. If you walk from Paris to Versailles, it will take longer than by car. Producing paper manually will take you much longer than having an automated production line. The same applies to It and software automation in It looks a bit different than in transport and manufacturing. So let’s look at it now. It teams use a variety of practices to automate their work both in software development and in the management and delivery of infrastructure such as servers, operating systems, middleware and networks. Part of their daily work is to evaluate whether the tasks they perform are routine and can be automated, and if so, they automate them. For example automated provisioning of the Infrastructure automated provisioning of the infrastructure means that when a software developer needs a storage database or a virtual server, that part of the infrastructure is allocated for him automatically, literally at the click of a button, and not manually.

That is, normally he would be waiting for a week to order licenses, running script, manually, and configuration. This automated provisioning doesn’t apply only to a part of the infrastructure such as a server, but it can be applied to the entire system that the customer needs. For example, automated provision of the entire issue for the end customer. Imagine that you have some of your products that you want to sell. Either you build a team of developers, business analysts and testers to produce an Eshop for you in a year, or you go to shopify. com where the server’s storage connection and everything needed is automatically allocated for you, literally on a click of a button. In the past, such a way of working wasn’t as easy as it is today because of the many new practices and tools available to automate It work. Today, I will show you examples of these practices and tools on next slides. Here are promised examples of practices for It automation.

For example, the practice of continuous delivery, which I will explain on the next slide in a moment. Other practices include containerization microservices, specific deployment practices and the cloud. It would take more time to explain all the practices, so I will only refer you to literature, which you will see at the end of this session. Amongst all practices, I’ve selected the continuous delivery, which I will try to explain briefly here. The picture is a simplification of how it is possible to automate the work of programmers so that customers do not have to wait for their new requirements. It starts with writing code. There are code analysis tools and unit test tools that give the programmer immediate feedback about code errors. The code must then go through a number of steps before it is delivered to the customers as a functionality.

For example, it must be checked into a version control tool. They must be compiling code testing and deploying it into the production environment. All these steps are often done manually, which is slow and the result is of poor quality. The essence of DevOps continuous delivery is to automate all these steps with tools. Examples of such tools are here. There are hundreds of these tools. Many of them are open source and they are continuously evolving and new tools are emerging. You can find overviews of DevOps tools on Internet, such as this periodic Table of Tools for Continuous Delivery so much for automation. We briefly outlined the agile and automation practices. Let’s now explore the last area culture change. DevOps is sometimes called a culture movement because many DevOps practices are related to the company’s corporate culture.

We said that DevOps goal is to dramatically speed up It. Now imagine it when a customer comes up with a requirement for the new functionality and an It worker sends him to someone else with words that’s not my responsibility. Another It employee says the same thing. When the customer finally succeeds and the project starts, the project manager and his team have the same problem the people around them don’t cooperate much and don’t accept responsibility. Well, you probably understand that in such a company nothing will go fast. Despite agile management and automation. You won’t start delivering 200 times faster when many people in the organization believe that it’s better not to take responsibility. It is a part of the corporate culture. Another belief that tends to be part of corporate cultures is that it’s better to keep information for yourself because they can be useful and we will know more than others and it pays off. So be a project manager, go and create a ticket for the project, get it approved by my boss and your boss and then I’ll send you the information. So in such culture you won’t be delivering 200 times faster.

Therefore, you need to change your corporate culture. Changing corporate culture is a difficult task and unfortunately we in It do not understand this area. We have insufficient knowledge and tools for such a change. This often leads to the fact that many organizations that implement DevOps focus only on automation tools and agile management and do not address the cultural aspects. Education can help here. Today, education is also very much focused on automation tools and agile management. These areas are easily accessible in It. There are many literature courses and online materials. While the knowledge needed to work with corporate culture is not available to It management, it is not part of It courses, literature and online resources. Education must make this area accessible to the It industry. In the future, education must answer the question how do you make your employees colleagues to work together and collaborate instead of avoiding responsibility and not providing information? Trying to think about how would you do that? In other words, how do you change the values and attitudes in your organization? You will probably say that you cannot and you will not do anything.

But that means you will not be DevOps and you will not achieve dramatic increase in the It speed. So summarized and underlined DevOps is a way to speed up It through a range of agile, automation and corporate culture practices. Agile is a delivery method where the customer gets functionality in parts. But very soon the teams are cross functional, organized around the service and have everything needed for delivery and operation of the service. In the automation section, we talked about automating the entire development process, such as continuous delivery, where the developer gets his code to production on a click of a button. It is also necessary to automate the provisioning and management of infrastructure offer automated provisioning.

It’s also important to change the corporate culture so that people’s thinking and behavior do not hinder deliveries to the customer, but rather speeds them up and where to find more information. This is the promised reading and training recommendation. If you want to get into DevOps easy way through a novel, I recommend the Phoenix Project, Budging Kim, Kevin Ber and so on. Or more technical continuous delivery budgets humble Training, which covers the topic the similar way as I’m covering is Dasia DevOps program, which starts with Jessa DevOps fundamental basic three day training. There are some more reading here recommended or contact me if you need any help or advice or even training or consulting. I wish you success on Odibob’s journey. It is not easy journey, but is definitely.

2. Differences between COBIT5 and COBIT2019

Welcome to the lecture dedicated to differences between COBIT Five and COBIT 2019. Please be aware that these are my own highlights and summary about how COBIT evolves from version five to version 2019. I’ve picked only the useful and practical changes that are relevant to how COBIT is used in organizations. If you’d like to see the complete list of major changes, please download the ISACA version, which is attached as a downloadable resource. Within this lecture I have divided the differences into three topics. First enabling processes change to governance and management objectives. I will explain all in a moment. Second, added focus areas such as DevOps and third, added the Design guide. Let’s explain each of these points one by one. The main content of COBIT five was the enabling processes book. I will remind you what this book contained. Here is the COBIT Five Enabling Processes book. And I have an extract from the book. I’ve used one of the processes which is called DSS Two. Manage service, request an incident. Remember, there are 37 of such processes. So I picked one only and they all have the same structure.

So as you can see this DSA Two, the rest of them will look the same way. Each process has as you can see besides title area, whether it’s Management or Governance and domains. In previous version we call that domains. We have domains as well. In version 2019, as you can see here, the process contains process description, purpose statement. There are also it related goals. Currently they are called Alignment Goals and how they are measured process Goals and Metrics here. So this is the heading for each process. Next you can see this resymmetric meaning who is responsible for each practice or activity? Practice here then you can see each practice and its inputs and outputs. So what has to be done step by step within this process and each practice is divided into activities. So you can see 12345 here activities. So this is the core structure.

So we can see more management practices and activities here, together with input outputs, management Practices and at the end of each process you can see a table with related guidance. Meaning where else you can find guidance frameworks standards that describe this DS Two managed Service request and incident process. So this is the content of COBIT Five Enabling Processes Book 37 such Processes be aware that originally in COBIT Five this book was not free, which is great about 2019 because the core book, which is now called Governance and Management Objective is freely downloadable even for Isaka Nonmembers, which is great. So what we’re going to do now, we’re going to explore the second book, the new one in 2019, where these processes were transferred to. Now. This book is called Governance and Management Objectives. And as I explained, we can we can consider this like a higher level title because the processes are inside the Governance and Management objective. We have 40 of them. Each has its own separate chapter and each objective contains one process. And beside process this is the big difference.

Each objective contains six other governance components such as Organizational Structures, information Fluency and Items, people Skills, Competencies and other. So again in COBIT Five the cost structure was 37 processes. COBIT 2019 it is 40. We have three new governance and Management objectives. We have already seen the Enabling Processes book. So let’s now walk through the Governance and Management Objectives book. So we will explore how the content has changed and how the processes are captured.

Now I know that the DSA Two which we used in previous example is on page 237. So now I’m in Objective not process anymore. This is called objective. Now, DSS Two managed service requests and incidents. You can see that the titles are same. And now what we have here so we have again there’s a domain name, there is a focus area which is the cork of it, the Objective title and Description and purpose. So now we’re no longer talking yet about the process, but an objective. We have Enterprise goals and alignment. Goals here. In a previous version we used to call them it Related Goals or it Goals. And now here where the process comes, we have a component A.

So we’re going to COVID all components here, which are seven of them. And the first one is the Process, which looks pretty similar as in the previous version. We can still see the practice here and inside five steps of activities and then we will continue later we will see more practices and activities. The difference as you can see here is the related guidance is directly within each practice. So we are not waiting until the end of the whole process but related guidance even here. So let’s see further also what is the new here we have capability level here directly these activities because in COBIT Five we had to take another book. To find these capability levels.

We had assessment books, they were specifically designed for assessment. But here we have it in one book here, this one. And you see more practices again together with activities and related guidance if there are any. So related guidance, again activities practices still in the process component still in the first part. And once we get to the end of this process component, we find component B which is Organizational Structures. So this is the next part. We did have these race tables in the previous version but we didn’t call them Organizational structures. We had them as a part of each process. Then information flows and items. We also saw them in the previous book in the COBIT Five, but they were part of the process. Now it’s separated into Component Information Flow and Items Inputs outputs from the process that’s component C.

Then we have D which we didn’t have exactly in this form in the COBIT Five structured like this. So it’s another component d people Skills Competencies where you see references regarding skills for this particular objective DSS Two managed service requests and incidents. Then we have policies and procedures. Again, this is a new part which wasn’t directly structured like this in COBIT Five culture ethic, behavior and component Services and Infrastructure and Applications. So this is the new structure in COVID 2019. The governance and management objectives. Book. So this was the first and the major difference between COBIT Five versus 2019. Let’s see another second difference which I find useful so far. I say so far because by now it only exists as a concept and it’s not completed yet. The Focus Areas a focus area describes a certain governance topic or an issue that can be covered by COBIT. That means that COBIT can be adjusted to specific conditions. Here we can see some examples. For example small and Medium Enterprises. I find this very useful to make COBIT available for small companies, or we can say adjusted for small companies.

There are some other focus areas like cybersecurity risks and especially DevOps. DevOps is extremely important topic these days and I find it crucial that COBIT authors will describe DevOps in relation to COVID practices and in future, hopefully it becomes an integral part of the COBIT core model. Well, focus areas sound great, but unfortunately at the time of creation of this course DevOps, neither Small and Medium Enterprises focus areas content wasn’t yet created.

Also, its usefulness will greatly depend on how well it will be described by the authors. We will see. And the third and last big difference between COBIT Five and Cook 2019 is a new book, COBIT 2019 Design Guide, which describes the design factors that can help the organization design their governance system tailored to their needs. Here is the overview of the design factors for example enterprise Goals this topic answer questions such as what if our enterprise goal is growth?

How do we set up our governance system in that case? Or what if we are operating in a highly regulated environment? How we should then set up our governance? Or what if we are facing a lot of software failures? These and few other factors which influence how your governance system will look like are called the design factors and COBIT otters did a pretty good job in describing in details what to do in the design guidebook. Quick glance into the design guidebook you can find in lecture Designing a Tailored Governance System walkthrough okay, so these were my top three practical differences between COVID Five and COVID 2019. I hope that helped and wish you good luck. With what whatever you are planning to do with the new COBIT 2019. Whether to study, implement or even forget it if you didn’t find it useful at the moment.