Release, Service Level, and Availability Management

Our next practice is release management, and its goal is to make new and changed services and features available for use. Now, as with other practices, there's a definition there of a release-- a version of a service or other configuration item or collection of configuration items that's made available for use. And like a lot of definitions, that's not the clearest. So, let's think about an example. So, a release can be a lot of different infrastructure components and application components that work together to give you new functionality. Let's take, for example-- let's take, for example, I know a lot of people don't do this now.

 

But you go to a computer store, and you want to buy-- you want to buy a new piece of software. And you go in, and you take the software off the shelf. And you go to the cashier. You pay. You get home. You rip the cellophane off. You open the box, and the first thing that you do is you've got the software. It's there on a CD or whatever it happens to be, and the software component, the CI, is available. But then that's not that all that comes out of the box. Quite often, there'll be a whole host of different pieces of paper that will be the keys to where to allow you to use the software-- the license key. You might well have information there about how to get support for the software. You might have information about software that you can use and that you can link with this software to support it.

 

There'll almost certainly be an instruction manual in there. There will almost certainly be an installation manual in there. And of course, the first thing on the installation instructions, it will say you must be rolling this particular type of hardware. You must be running this particular type of graphics card and so on and so on and so on to allow you to get the benefit. If you've not got the right combination-- hardware, software, documentation, license keys, training-- it ain't going to work, and you're not going to get the benefits from any new features or new services or that piece of software that you've bought from the local store. So, making sure that we know it's hardware, it's software.

 

But also, there might be all the documentation, training for users, training for IT staff, updated processes, updated tools, or any other components that are required to make that release work. Now, what makes it particularly complex often is that each component of the release might be developed by separate service providers and/or procured from third parties done internally. And you've got to integrate all of that together. And I don't care what environment you are working in. That integration of your release components in DevOps, in Agile, in service management is always going to involve pulling together different providers, making sure that what's in that release has been integrated so that you get the full benefit.

 

What release management will then go on further to do is to produce a release schedule, a document. It's used to document the timing for new releases. Obviously, it makes a lot of sense if that's actually synced with the change documents that's used to schedule changes. The change will control the release. The release is just what you actually push out there. It's the change that controls it. And if the release schedule says it's going to be-- it's going to be released at one time, the change schedule says another recipe for disaster, so making sure that's synced is also particularly important.

 

So, on the left there we've got our release plan. What that's going to do is make sure that we've got the right new or changed infrastructure that at the top, we've got the training, the documentation, at the bottom, and we've got the actual change software in the middle. Now looking at that, we're making sure in the release plan that we've got the right combination of hardware, software, documentation. Now, the hardware might be-- now these days the hardware might well be a container that you're going to run in. The hardware might well be a script.

 

It might well be all virtual hardware and infrastructure. And it changes every time, and we're into then mutable and immutable infrastructure, which is beyond the syllabus here, but I thought I'd mention it. So, then we're into new or changed software. Again, what we can start to think about as well and are linking to deployment management, I'm thinking about how we're going to deploy this release. And that's where we move into areas where-- so much jargon in some of these areas that I sometimes can't believe what we're moving into areas of blue green or A B releases and feature flags-- where what we're doing is mirroring production environments and only releasing certain features to certain people.

 

All that's going to be passed is the release plan. Also, in that release plan who, how, where, all of those questions are going to be answered. Is it going to be thinking about release plans certainly in the Agile and the DevOps world all the way from committing of code right the way through certainly and continuous deployment, right the way through from committing code, all the way through all of those different stages, all controlled by change control, right the way through to it landing on the user's tablets or whatever else it happens to be, all of the automated but still all controlled, all going through release management, all going through change control.

 

These things need to be thought about together in any environment as I say all the way through to things like continuous deployment, continuous delivery. And then finally, right at the very end there, if you do it, review it, making sure that once we have deployed, we review the release. Did it work? What did we do well?

 

What do we do poorly? What can we do better next time? Did the users get the benefit? Did we hit the right people with the right features? Lots of questions you can ask in review and take that learning back into your next release plan.

 

Service level management's goal-- set clear business-based targets for service performance so that delivery of a service can be properly assessed, monitored, and managed against these targets. Now, one of the things we've seen about services is that they're kind of like jigsaw puzzles. They're made up of people. They're made up of products. They're made up of assets. They're made up of CIs. So, services look very, very, as I say, like a jigsaw puzzle. So, what we want to do is have an end-to-end view of that service. And that's what service level management's key role is, to help us see that end-to-end view of the service, so clear business-based targets. Immediately we start to use very IT-based targets to manage the service. And people in our organization, like users and customers, don't necessarily understand those targets.

 

They immediately feel nervous. They don't necessarily trust the service provider. So, we're going to make sure that we've got them. We're going to need to be able to measure them, and monitor them, and assess them, and look at those targets. What we want to know is, are we doing a good job in delivering the services that the organization wants. One of the problems we've seen with service level management over the years has been the fact that service level agreements, where we document all of these various performance targets, have been written very much from the service provider's perspective. So, the figures in the SLA look very, very good and all of our numbers agreeing. But the customer thinks the service sucks.

 

So well, yeah, that's going to be a problem. Now, what you end up with is what they call the watermelon effect of SLAs, where they look green on the outside. But they're red on the inside, something that we've got to absolutely guard against in service level management. So, we've got to be able to monitor and to manage against these targets. We've got to know what good looks like in terms of the service that we deliver. So, that means the definition, the agreement, the documentation, and the active management of service levels. Now, that's going to require some certain skills from the people who are involved in this.

 

And this very much at the operational and tactical levels of the service interaction. Relationship management is going to be important in two ways. Relationship management smaller, where we're just managing the relationship with customers very often and uses. But also, relationship management, the general management practice where we're also making sure that we've got the different view of the service that's strategic and high-level tactical people have got, mixed and managed with the view, the tactical and operational view, that we get in service level management. Business liaison is important to make sure that we understand what the business wants, making sure that we understand when they need it, why it's important, understanding in service level management what good looks like, but also why good is important, actually having empathy with the customer.

 

If the service fails, this is what it means to them. And one of the other things as well, as we've said before, many of these services are supported by both internal and external. We kind of got two supports. Internal and external providers are supporting the service. So, as you can imagine, there are certain commercial and supplier management skills that are going to be needed for people in service level management.

 

Doesn't necessarily mean that they're going to be supplier managers. But they need to work closely with those guys to ensure that that's a external third-party pillar, doesn't crumble.

 

And they're going to work internally with their own people in incident management and other areas to make sure that that internal pillar doesn't crumble. And if both of those pillars stay strong, we're going to hold up the service.

 

Service level agreements have long been used as a tool to measure the performance of services from the customer's viewpoint. And it's important they're agreed in a wider business context. Using SLAs might present a lot of challenges for organizations, because often they don't fully reflect the wider service performance and user experience of actually using the service. And what we've seen happen recently is more a looser experience level agreements starting to enter the fray. But what service level agreements have got to do is, number one, is they must be related to a defined service that's there in the service catalogue.

 

They're not just simply just a bunch of metrics that have got no purpose, that don't provide visibility or reflect what the service actually does. Now, I've seen that from both perspectives in my time in service management. I've seen it more often where the service level agreement doesn't reflect the customer's actual view of the service.

 

But I've also seen it the other way around where a service provider believed that the service level agreement didn't actually reflect what they did for their users and for their customer. So, you need to be-- you need to make sure that the service level agreement actually reflects an agreement between all of the stakeholders. So, it's making sure that sponsors, customers, users, service providers are all happy with, and the service provider is happy with, that service level agreement.

 

Now, I call it an agreement. What you tend to find in many organizations-- please, please, please, please, please don't treat it like a contract. Service level agreement is the document. It's got to be written simply. It's got to be easy. It's got to be easy to understand for all parties.

 

Make sure that it's not written in legal language with all the heretofore withstandings in there and all this sort of stuff that basically just freaks people out completely if they see it. It needs to be clear. It needs to be concise with no ambiguity and making sure that we can measure everything that's in a service level agreement. The service must remain good. Define good.

 

Yeah, there's got to be something more in there, in the service level agreement. And hopefully, it's going to relate to defined outcomes and not simply operational metrics. Again, that's what led to the watermelon SLAs that I've described where we just have metrics about the availability of servers, the availability of network, the availability of software and databases.

 

And it didn't really hit the spot with the user, because they just didn't understand that. What they were seeing in all of that green just didn't reflect their view of the service and whether it actually performed.

 

So, it's got to be written simply. It's got to be easy to understand.

 

And partly, it's got to be easy to understand, because a lot of the targets in there are going to be used by the incident management practice to give you the targets, going to be used by the change control practice to give it the targets for a lot of the work that it does.

 

Well, here's a list of activities, and measures, and metrics that service level management is going to use. I'm actually going to start by taking them backwards and looking at business metrics first. What metrics have we got in the service level agreement that are actually metrics that the business considers ones where it believes that if this is happening, then it's absolutely the service is working. One organization I worked with one or two years ago, they were working in the health care arena, and they were delivering health care products to hospitals around the UK. And one of their key metrics was, does the service and the IT service help us to deliver on time in full.

 

And they used to call it OTIF, yeah, on time in full, in terms of older fulfillment for them. So, does the IT part of that help them to deliver it? And that was warehouse systems, and that was ordering systems, and fulfillment systems and services. And they all contributed to that single OTIF measure. Business metrics. Operational metrics are going to be the ones where we're looking at lower-level types of metrics, such as how quickly do we respond to incidents, how quickly can we restore the service, how many rings do we answer the telephone, and wherever it happens to be.

 

The lower-level operational metrics. Moving backwards and moving upwards, we look at customer feedback. So, we're going to be looking at those metrics, but we need to look at customer feedback to get the softer view of the service.

 

So, customer satisfaction surveys, whether they be after an event. So, after incident management has closed an incident off, customer satisfaction survey is sent out about the service and your support element of the service. Or they could be more periodic surveys that are used to gauge the feeling of the customer for the service over a particular period of time.

 

Any key business-related measures as well. Getting feedback on, well OK, here's your service level agreement. There are 25 different measures of service in there. Which are the most important to you, users and customers? So, you get them to rate.

 

The idea being that what you do-- if you're going to miss an SLA, miss the SLA on the 25th out of 25 important metrics, rather than missing it on metric number one that the customer considers important might seem like cooking the books a little bit, but certainly worth thinking about.

 

And the final one up there is we're going to have to think about getting feedback through customer engagement. Now, this is very, very important that we've talked there about-- well OK, you might say, well Barry, aren't we getting customer feedback through surveys and so on?

 

But senior people, particularly sponsors in organizations, they don't fill in customer surveys. It's a reality, it's a matter of fact. Go and talk to them. Engage with them.

 

See, you know-- actually go there, sit with them, talk to them. See what they feel about the service. See what they feel that you could improve. On what you've got then is a big, big, big interface between service level management and how it gets involved in the improve part of the service value chain, which is where we're going next.

 

You can see the two dark ones here are plan and engage. To be honest, if it was me, I'd be making improve a really dark one as well. So, plan, service level management supporting planning, and service portfolio and service offerings with information about actual performance and trends. So certainly, we're looking at where the service is performing. You want to make a service portfolio decision on whether the service is going to remain, or it's going to be one that's phased out.

 

Then certainly, service level management and the performance and the trends can be useful in that respect. Improve service level management-- it says that can be a driving force for service improvement. No, service level management is a driving force for service improvement, period. Engage-- service level management ensures ongoing engagement with customers and users through feedback processing and continual service reviews. Yeah, absolutely, we just talked about making sure you're talking to stakeholders, making sure you've got that engagement with the customer. You've got that engagement with the user.

 

You've got the feedback from surveys. So, service level management-- huge role to play in engage and understanding what it is the user, the customer, the sponsor even wants from the service. Service level management into design and transition that inputs into design and transition and changes. Yeah, service targets-- what kind of service does the customer want? Does the customer need?

 

Giving the design people, the transition people hard targets to work to in terms of the services that they're designing and transitioning. Obtain and build service level management-- little bit of involvement here providing objectives. More about the performance-- it's kind of removed quite a few stages here from service level management gives a target for availability and that therefore gives a target for the components that make up the availability. So, if you're building a service, the idea being that you've got to design in and build in availability into a service, for example.

 

Then the targets are going to come from service level management. Finally, in delivering support, down at the bottom, service level management, communicating service performance objectives into operations-- we mentioned SLAs need to be clear and concise to make sure that the targets can go into incident management and change control.

 

Obviously, deliver and support-- a major, major element of that and obviously, as well collecting the feedback as an input for service performance. So, all in all, service level management-- get and involve right the way through the value chain.

 

Our next service management practice-- availability management. Availability is absolutely at the core of satisfaction for users and customers. The more available the system, the more available the service-- typically, the more satisfied they are.

 

So, availability management's role, in particular, is to ensure that services deliver the agreed levels of availability to meet the needs of the customers and users. As ever in these things, we've got a definition for you you'll want to remember for the examination. Availability-- the ability of an IT service or other configuration item to perform its agreed function when required. We'll look how we measured availability a little bit later on.

 

Let's have a look now at some of the key activities that availability management actually performs--negotiating and agreeing availability to achievable targets for availability. Now, it's important to understand that service level management also gets heavily involved in that activity to negotiate those targets because availability targets are some of the targets that we will have in the service level agreement but not all of them. So, certainly, that role there in availability management is one that's quite often shared with the service level management practice. Designing infrastructure and applications that can deliver the required availability levels-- this is a personal thing. I happen to think that this is absolutely the most important thing that availability management does to make sure that they design applications that deliver the required availability levels. The cost of retrofitting availability is incredible, and it's very difficult as well.

 

It's not like you can go down to your local computer store and say, excuse me, can I buy 3% availability, please? Just doesn't work like that. If you want 99.9% availability, you've got to design for those kinds of availabilities where there's a classic availability measured of a service when it's measured as a percentage. We'll look at some other measures a little bit later on. But there's a classic measure the five nines, 99.999% available.

 

That means you can afford to have a full 5-and 1/4- minutes downtime in any year. Yeah, not a lot of leeway for lost performance there-- so designing infrastructure and applications that can deliver required levels. Ensuring services and components are able to collect data required to measure availability-- so quite often, there's a whole host of things that we need to do. Now, it's important as well to measure availability, particularly when we start to move into virtual environments, the availability monitoring, the ability to collect that data-- bang-- is switched on the second we create the instance or whatever else that we're going to run, all the infrastructure we're going to run or a container for the service that we're going to run then the availability starts are switched on straight away.

 

So, it's again, an important design activity in that. Making planning improvements to availability-- improvement, improvement, improvement-- it's everybody's role, continual improvement within the service management environment-- so understanding, planning the improvements to availability, making those, making those, but cost justifying them as well. It's one of the realities of availability management that very often, the organization will not know the cost of downtime. And if you say to them what's the difference between 96% available and 97% available? They'll say 1%.

 

Yeah, OK, very good but what's the difference in terms of what it's costing us as an organization? 1%-- no, no, no, you're not getting it. Where's it hitting is in the pocket. Where's that going to start to hurt us? Oh well, I don't know.

 

So, it's important that we understand when we're planning improvements to availability, it's not just improvement for improvement's sake because, as we get closer to 100% available, the cost of achieving that level of availability really does skyrocket right the way through the roof. And then finally, monitoring, analyzing, and reporting on availability-- so making sure that if we start to have availability issues in a particular area, you can immediately, hopefully, say I'm going to work with continual improvement.

 

I'm going to work with problem management. I'm going to work with incident and service level, and that we can monitor. We can analyze. We can report on availability. And hopefully, we can go back and improve it.

 

Finally, as part of availability management, we're going to look at some measures of availability. Now, thus far, I've talked about the classic percentage availability, which is worked out by what's the amount of time that the service should be available. It's 9:00 to 5:00 Monday to Friday-- that would be 40 hours. How much it was actually available-- so it was available for 36 of those 40 hours, then we've got a 90% availability. That's been traditionally used, and still, in many organizations is used as the measure of availability for a service.

 

But to be honest, we need to be a little bit subtler, a little bit more cunning, a little bit more creative in how we measure availability. So, we've got some other measures here. It might be the user outage minutes. So, it could well be that you might have a five-minute outage when there's only one user using the system. So, total outage-- there was a total outage that was five user minutes. And, it can be useful as well because you can look-- you could have a five-minute outage when there are 1,000 people using the system.

 

And therefore, you've got a 5,000-minute-- you've got a 5,000-minute user outage minutes measure of availability. You could have a six-hour when there's only one user using it, and you've got a 360 minutes-- user outage minutes. So, there's an interesting one as well. So, it gives more of a balance about what time the outages actually occur when we look at user outage minutes, as does the number of lost transactions.

 

If you're an Amazon, for example, and we're in the run-up to the holiday season, to Christmas, the number of transactions that you're going to lose in a short period of time on, let's say, December 19th or December 20th or Black Friday or something or Cyber Monday or whatever it happens to be. The number of outages, the number of transactions you're going to lose in those times over a period of an hour is going to be say far more than you might lose at 3:00 AM on a cold February morning where there's probably nobody using your-- not very likely to be people using your service.

 

So, the same one-hour availability, unavailability actually costs a lot more in terms of lost transactions. Lost business value actually takes it all in terms of money and business-- when we look at value. OK, not everybody measures it necessarily in terms of dollars or pounds or euros or whatever it happens to be. But certainly, the lost business value of an outage can be a target and a measure.

 

Sometimes that's what that money is a little bit tricky to measure because you're not sure that all the value that you've lost is necessarily down to IT failure. The final one might seem a little bit weird-- user satisfaction with availability. And, you know, you're thinking, well, that's not very empirical, is it? But if I want to use an ATM, the ATM could've been available every hour for the last seven days.

 

If it's unavailable in the five minutes that I want to use it, then my user satisfaction level with that ATM is going to be very, very low, and the availability of that ATM is going to be very, very low. So, what we're trying to do with our availability measures is a balance so that we've not got them skewed one way or the other-- too much to odds, too much to odds. Some of the really low-level availability of servers and systems or too much geared towards user satisfaction. We're looking for that balance.

 

So, capacity and performance management practice usually deals with service performance and the performance of surpassing resources such as the infrastructure, the applications, and third-party services. In many organizations, now this has been extended to include personnel. Service performance and capacity are dependent on those of the components and the services, so the whole service and the performance of the services is dependent on the components. It's dependent on the people. It's dependent on the application. It's dependent on the infrastructure. It's dependent on its links to all the services.

 

And we're looking at that in an end-to-end perspective. So, the role of capacity management is to ensure that services achieve the agreed and expected performance, satisfying current and future demand in a cost-effective way. It's kind of like the right capacity in the right place at the right time at the right cost. If we've got too much capacity, then it's going to cost us-- maintaining stuff we don't use. If we've got too little capacity, then almost certainly, we're going to get failures and performance issues.

 

So, let's look at some of our definitions, performance and a measure of what is achieved or delivered by a system, a person, a team, a practice, or a service. Service performance-- usually associated with a number of service actions performed in a time frame on a time required to fulfill a service action. So, you think about transaction rates. So many transactions an hour.

 

Each transaction not taking longer than two or three seconds. That's where service performance looks at. And then service capacity-- the maximum throughput that configuration or a service can deliver, and that's really, really important that service capacity, particularly looking at the components of that service. If you -- the throughput of a particular component might be a 100 bananas.

 

But if you want to achieve a particular level of performance, in terms of response time, well, actually, full is only 75 bananas, so it's only so much of the capacity that you can use if you want to achieve a particular performance. And that needs to be understood because lesser mortals, like me and you, will understand capacity and say, well, actually, it's full when it's full. Well, actually, that's not true from a capacity and performance perspective.

 

Final one of our service management practices is service continuity management and a very biblical start to this one. In the beginning, there was nothing. We never used to protect IT services against disasters. And that was simply because 30 years ago, we never used IT enough, and it was never prevalent enough for us to need to protect against disasters. And then along came disaster planning, but it still wasn't something in an organization that was particularly well planned or well delivered. And that was partly because there was a head in the sand attitude that all of this money that we're spending on disaster planning is wasted money. There's no real value. And, of course, disasters happen to other organizations, not to ours. And it certainly was, again-- God rest their souls-- it certainly was the 9/11 that brought us into a view that actually we do have to start to protect IT services. And in ITIL version 2, we were into contingency planning. And then ITIL version 3, IT service continuity came out.

 

And here, ITIL 4, we've reappeared with service continuity management. It's still got the same goal, making sure that the availability and performance of a service is maintained at sufficient level in the event of a disaster. And there can be a whole host of different disasters that you need to look at. They can be as simple as power failure, flood, fire, denial-of-service attacks, lots of different-- right the way through to-- right the way through at the other end to potential disasters that could happen, like well, we could even go for asteroid impact. Of course, that will never, hopefully, that will never happen. And if it does, it's always going to hit New York anyway, and Bruce Willis and Morgan Freeman will be around to sort it out, so not a problem.

 

But we can look at those difference-- I do know actually one organization that looked at the cost of building their IT center under the Alps to see whether the cost of that would actually be prohibitive in case of asteroid impact. They decided that that was going to be a little bit too expensive based on the probability of asteroid impact. So, we look at all of these different disasters.

 

We've got to maintain services a particular level through them. So, the major goal is to support an overall business continuity management by ensuring the required information technology and services can be resumed within required and agreed business timescales following a disaster or crisis. So, if we think about a denial of service attack to a primary location, it's business continuity. It's not just about the IT services. It's about the whole business continuity. And what we've got to be able to do is to support the business need. We're going to take a bit of a look at some of the key terms and phrases and activities on the next slide.

 

So, let's look at some of those key activities in service continuity management. The first activity, after we've secured funding of course, is business impact analysis. So, what's business impact analysis all about? It's about understanding what will be the business impact if we lose certain services. So, there's got to be some sort of prioritization of what we bring back and how quickly we need it back, and in what state. The business, the organization, the customers, the stakeholders, they've got to make those decisions. IT cannot make those decisions. The service provider cannot make those decisions for them. I remember talking to one organization some years ago. And their head of IT said to me, every year, Barry, I go to our business, and I say to them, what are the most important services? What do we need to protect? And every year they say to me, oh, you decide. And he said to me, to be honest, they had it very, very easy many years ago when we had a mainframe. Because we protected the mainframe. And they got everything back. Because we protected the mainframe.

 

Now, with distributed systems, it's just not as easy. But they've not got that through their heads. And he said, what I want to do one day to get my own back is I want to take the head of our marketing department down into the IT suite. And I'm going to say to them, what's the most important piece of kit in here? What are you asking me for? I know nothing about IT. Well, you ask us every year to make the decision on what the most important business services are. Oh, it's that one over there with the flashing lights. No. That's the vending machine. You might argue that's the most important piece of kit down there.

 

But you would never do that. Would you? Yet, you've got to make sure that you've got that business impact analysis done by the business. So now, what normally falls out of that are two different measures, a recovery time objective, and a recovery point objective. In other words, how quickly do we need it back before our scale of losses disappears over the horizon? And at what point do we need it? Let's think about, for example, if I'm Amazon. Yeah. If I'm Amazon, all I've got is my website. Well, it's not all I've got. But typically, all I've got then is online shopping to make my money, my website.

 

Without my website, if I lose that, my recovery time objective is, hell, I need it back straight away. Eh? That's going to be important. Yeah. They've got to have it back straight away, as quickly as possible. But also, what you've got is the recovery point objective as well. So, what state do they need it back in? Well, it failed at 5:30 AM this morning. We've got last night's backup. Yeah. We've done millions of pounds worth of business between the two periods. And we've lost all of those customer transactions. So that's OK. Isn't it? Well, no. It's not. We need that recovery point to be as close as possible to when it went down. Now, there is an unwritten rule. Well, it's an unwritten rule, but it's a truism.

 

The quicker you want it back, the closer you want it back to what it was before it went down, the more expensive it's going to be. And business and service continuity are like a big insurance policy. It really depends on the value of what you want to actually protect, how much you're prepared to pay for insurance. Once you've got the import of business impact analysis, recovery time objectives, recovery points objectives, you've looked at the different types of disaster, how they will affect different services. Ooh. How are they going to affect different services?

 

Remember those service models before from service configuration management. That configuration management might be very, very useful in helping main service continuity understand the impact of potential different types of disaster. So, almost as if all this service management stuff was designed to work together. Isn't it? So, that's going to allow us then to go on and create disaster recovery plans. And the plans are going to detail who, how, why, what, where, when, who's going to be involved, how they're going to recover the services, when they're going to recover, where they're going to recover.

 

Is it going to be off site? Is it going to be on site? Is it up there in the cloud? Whatever it happens to be, you build the disaster recovery plans. Over a period of time what you'll also do is test those plans. You might dry test them. Paper exercise. You might test them in full. You might do unannounced tests. And if you think about the way that a lot of organizations are doing this, I've got this kind of approach now to make sure that they've got very, very robust systems. Then you've only got to Google chaos monkey and look at what organizations are doing to try and ensure that their systems are robust, and that they can protect them whenever there is a disaster.

 

So, our technical management practice that we're going to look at is deployment management. And it's that move new or changed hardware, software, documentation, processes or any other component to live environments. It may also be involved in deploying components to older environments for testing and for staging. Obviously, deployment is very, very big in the DevOps world. And the end to end and the automation of deployment, we now see as something that's very, very prevalent in the digital world. What we're going to talk about from a deployment management perspective, and what the syllabus deems important, are the four following approaches. I'm going to group -- the first two I'm going to group together is a phased approach and a big bang approach. Sometimes there is no approach to deployment other than, bang, everybody at the same time. You've got to do a big bang approach in many, many cases where something is so vital, it's so critical to the organization. And it might be that, particularly, if you're updating for things like legislative changes or something of that ilk, then you certainly might need to do -- certainly need to do a look at big bang. Now, obviously, big bang means that you're doing everything at once. And that can make it cheap to do. But sometimes, a big bang adds more risk, particularly if it doesn't work, and you've got to fall back from that.

 

The counter to big bang is the phased approach, where you deploy to many different places, but you do it in a phased fashion. And it could be on a daily basis, on a weekly basis. And you can deploy and switch on using the feature switches and the blue-green releases and so on that we talked about before. You can switch on at different times. So, you can have a phased approach to deployment. The value of that is that, obviously, you get feedback very, very quickly, but from a limited group of people, so meaning that if something goes wrong, then you can draw back and you've not lost time, money, resources, and so on in terms of doing that big bang deployment. Some of the other approaches that you'll be used to from your mobile phone, your cell phone. When you go home, it gets onto the home network.

 

Three-quarters of your apps decide they want to download, and you can actually decide if you want to pull the deployment. You've got control as the user. You've got control as the customer. Obviously, if something's got to be in, and it's time critical, then at some point, the ability to pull-- I know at Global Knowledge, when we do our software releases, there is a particular date by which they need to be in by. But we can pull them down, as in when we need them. There are a whole host of applications that we can use in our organization. Not everybody needs every one of the applications. But they're on a whitelist. That means that we can pull down and deploy when we're ready to do that. And then the final one in there is continuous deployment.

 

And continuous deployment is a term borrowed very much from the kind of DevOps and the Agile world, continuous deployment, where what we're doing is-- we're going right away from somebody committing code, all the way through testing, deploying to dev environments, deploying to staging environments, deploying into testing environments, deploying into pre-production environments, all the way through to the production environments, and deploying right away through to the production environment, so long as that code that was committed back there passes all its tests.

 

So, we've got the idea of continuous deployments as well. Obviously, one of the other things from a deployment perspective, not necessarily included in those approaches there, is where we've got the aspects of continuous delivery, where in the DevOps world, something is ready to be delivered and ready to be deployed, but there is a finger on the button. So, were it me, I'd be adding push into deployment management as an option there. But that's not in the syllabus, so don't tell anybody. OK. So, that's it for deployment management.