Welcome to the Idol framework. Updated course from Cyber Eri i G.
My name is Daniel Riley. I'm your subject matter expert on the idol framework.
In this video, I'd like to talk about the service transition phase goals and the processes and sub processes that make it up.
No, in this phase, we're really talking about building the components that make up a service, Uh, and planning out the changes required to the architecture and any existing service is to carry through everything that we've done in the
strategy and the design phase. Up to this point,
this is where we really put it all together.
These are processes that are gonna make up the core
of a good service transition process.
We're gonna have a change management framework. We're gonna have, ah, solid change evaluation methodology.
We're gonna have a project management architecture, and we're going to deal explicitly with our application development standards. A cz well, a czar release and deployment management. Then we're going to do our validation. Testing on all of our service is,
and also we're going to have asset in configuration management and knowledge management,
but to make sure that everybody stays up to date.
Now the change management process is really about defining a change. Um, and what areas of a system are going to be affected
than communicating that change to this steak or stakeholders involved? Whether those air clients or internal team members usually it's going to be a combination. Once we communicate those changes, we're gonna want to actually embed the mentor culture. And by that we mean
were warding the types of behaviors that change
promote. So early adopters of a new service might get discounts is a way to embed that in the culture on things of that nature on. And then we're gonna prepare our organization through teaching. Um, and we're going to
I have information available to clients to help them understand how to utilize
our changes to the best of their ability.
S so, like I said, we're gonna want to use our change management process to monitor the life cycle of our changes so that we can
make changes in a fast paced environment without accepting too much risk. Thio interrupting our service is
s o. The sub processes that make up the overall change management process
are the change management support, which really is like most of our support. We're going to define our templates of documents that we need, as well as the guidance for formulating a good change request in our organization.
Then we're going to have a new assessment of proposals process, which is really where our change management framework takes the current change requests that have been proposed in the previous strategy and design phases
of and turns them into actual requests for work to be done.
Now. The request for comment, logging and review phase ties this together with the service design phase. If you were called at that police, we have a request for comment that we place out our documentation through.
This is the process that takes that in
and does a formal review of that information and updates all of our R F C logs.
take our time with changes. Some changes need to be done in an emergency basis and therefore will have an emergency change assessment process which allows us to rapidly assess these and get them authorized for implementation.
Uh, otherwise, we're going to go to the business manager and we're going to have hit change assessment done by one of our business managers
and that business major will decide whether or not they're able to authorize this level of change. If it's within their power to authorize minor changes or moderate changes, they can go ahead with. The authorization
otherwise will go into a change assessment by
the Change Assessment Board on Now. This is a committee ruling on the proposals to make sure that the design is meets approval to get development.
Ah, once we go to that, we have the change schedule and build authorization process, and this essentially takes the work breakdown structure on assesses. The resource is that will be required to fill it out,
um, and then places it on the development schedule along with assigning the resource is to it on. And this is really the plan to have some part of the service components built over time.
Then we're going to go through the change deployment authorization process, which is basically to determine if all the change components meet the agreements that we have set up in the design requirements.
And then we're gonna awful lot authorize that were released to production environment. This may be updating code or database instances,
is going live with the service or the components that have been created for the service to this point.
Now we have a separate minor change deployment process.
Sometimes we'll have processed. Or sometimes why have changes that we know are fairly stable on, and there's very low risk with implementing them. And these would be an example of one of the changes that a business manager may authorize without the need to go to the change assessment
Now. For any of these changes were going wanted to a post implementation review, which is again to assess the life cycle after the fact and to to look at the results we were able to achieve and see if there are any advancements we can make for future generations.
Now the change evaluation process is really about assessing major changes, so this would be something like introducing an entirely new service or restructuring the architecture of a new existing service with customers in use.
When you go through a big change like that, you're going to want to do an even more stringent control
of the changes that underlie that,
and that's where the change evaluation process comes into place.
So here's just some example things you're going to want to record in your framework. Who,
what, why and how are the general ideas of what I like to tell people to record.
So the sub processes that are involved with that
are all about the different phases. You're going to do a check prior to each face, so our 1st 1 is going to be a cheque prior to planning on. This is really to assess the conceptual design that has come out of the service design phase and
see if it's really a feasible concept.
Um, and then if it is a feasible concept, we're going to plan it out, and then we're going to assess it again prior to building it. And this is reassessing the concept. Now wait against our plan to actually build it out of the resource is
on structural changes that are required.
Then if we decide to go ahead, we're going to build it, and then we're going to reassess it based off of what we've actually built and verify that all of the components that we test actually meet the requirements and the assumptions we made up to this point
and again. After we implement one of these large changes, we're going to do a post implementation review for the same reasons we want to meet our make sure we met our objectives. I wantto identify anything that we can learn.
Project management is really about The coordination and planning of resource is that it takes to do a major request.
Um, and we're gonna monitor the cost, time and quality of our projects, and that gives us an overall scope.
Now, this kind of shows
a very familiar picture. If you happen to be from the world of project management a CZ I am,
This is called the Iron Triangle. You'll generally measure your projects on cost time and quality on. Do you get to pick two of these that you can hold on to? One of these has to be flexible. For instance,
if you want something that's going to be at fairly low cost and fairly high quality,
it's going to take you a long time to build it
there, as if you want something that's going to be high quality and not take a long time to deliver, you're gonna pay big bucks for it.
So the sub processes that make up the project management process start with Project Initiation, which is where we define the stakeholders who has an interest in the outcome of the project, the responsibilities of the people involved
in the resources that were willing to
two steak to the project. Um And then, of course, we're gonna want to document our project specific risks and constraints in any assumptions that were made during the design phase. We're going to want to make sure we explicitly define those here.
Project planning and coordination is really where we ensure that the building of the service goes on to the schedule that we plan and that we're making sure all of our resource is all of our development activities are coordinated across all of our projects.
So the project control phase is really the sub process that where we're actually applying the controls, this we're going to monitor the progress. And if we see any problems, we might initiate some corrective actions. On def, we see something that can be moved ahead
more quickly. We might expedite that as well.
Now the project reporting in communication phases much like all of our reporting in communications sub process is, um this is where we provide the overall summary of what's been planned or ongoing projects in the service transition things.
And this is used to inform our clients customers
in any service managers of the progress of our changes.
Now the application development process isn't actually mentioned in the Idol books all that much. But I would argue that there is a real world need for this process, as a lot of application development actually goes on,
even in companies that don't deal much was software,
and I'll show you what I mean by that here in a minute. But this, uh, idle framework does integrate with other frameworks. For instance, the agile framework, which is a software development life cycle, can be integrated with Idol
eso. Because this is an official, there aren't going to be any so processes defined. But this is kind of a graphic of what I like to think of his application development. It's more than just writing code or deploying applications.
We help with application migration
Web Enablement, which is helping an application which isn't typically available via cloud distribution or Web distribution making that work application enhancement, which is adding code to existing
applications to make them work better or more custom
and several others on here. That's not just about writing a piece of software or client facing software,
not the Reese deployment process is really about making sure that thesis service components that we develop move through the entire life cycle in a controlled manner.
Um, and this might be moving components through the testing environment to the staging environment or possibly out of the development environment into production. Something like that.
Now, when talking about the release and deployment process, I like to remind people of a quote from Eisenhower, and that's plans. They're useless. But planning is essential. Um, and that's just really to say that no matter how well we define our deployment process, we have to expect
that things were going to go wrong.
So here are some sub processes that will make up our release deployment process.
Um, that's the management support, which is like all of our support, Um, this is where we define the framework. Um, what the lifecycle components and stages that release will go through who's responsible, and then the sanity checks
that we're going to use to make sure that our releases
are are meeting our needs. And we're gonna want to do this even if we're in a continuous integration and continuous delivery environment, don't fall
into the trap of self documenting, continuous delivery. Um, always make sure you explicitly define your deployment steps
outside of the program that implements them as well.
The release planning sub process is really about the actual work getting put through the environment. Where is in the project management phase? We came up with a plan time wine of developing the pieces.
That's more of an optimistic view. Where is this version of assigning them too?
Planned release cycles is more like a bus schedule. It's goingto happen whether or not the components are ready. Uh, and if they're not ready, they'll just be on the next bus
so that Dev Ops is going to define the scope in the content of each of these releases on. And that's really what we mean by. If it's not ready, then it won't be on that particular bus. It will be on the next one,
so the release build sub processes about collecting all of these little components that make up a service release, gathering them into one area and getting them ready for testing team to come in and really put him through their paces.
Eso once we finish the release, build process all of the components for that particular release.
Ah, will be ready to get tested.
I'm during the release deployment All those pieces that have been approved through the testing, um, get pushed into the life production environment
and then the end users are going to be trained on any significant changes or any impact items on a lot of times will see this come out in the form of a change log in software or a service package update
like in the newsletter, something along those lines.
Now, back to the quote about planning being essential. We understand that even though we've tested and we've checked all of our
components up to this point several times, we still understand there are bound to be issues. And so early life support is really a process about being able to rapidly triage and respond to issues. When we move a service into the production environment.
Ah, once we leave the early life support and the service is sort of stabilized will enter the release closure sub process. This is really about updating all of our documentation and making sure that our service portfolio
ah, and our configuration management activities are all up to date.
So this is just kind of ah lifecycle diagram. Example. Um, you'll start with your release policy, which comes out of this, the strategy on and then the support phase. You'll go into your planning, and part of your planning will be to gather the pieces of software and hardware that word
in the service design phase. You'll then build and configure the set up for that release. As we said in some kind of testing environment,
it then gets put through quality review and what passes is released and then rolled out. According to some plan,
we then communicating, train our users on our changes, um,
at as part of our implementation, Um, and then we're going to verify
our implementation. Andi, I'll get more into verification in just a moment but on and then we'll make sure that we add all of that into our change management database so that we understand the current state of all our service is.
So let's talk about the asset config management process. This is really where we maintain the information about the different components, be they software machines of
or other ah, third party service's or even internal service is that we maintain configurations on on these items were called C I's configuration items, and these are what we need to deliver a service
and the interdependencies of those configuration items
So the sub processes were going to use to manage our configurations. Um, we're going to first identify what we need to configure and what we need to manage. Um, and this is the underlying structure of change management or configuration management. Sorry,
Configuration management systems.
Um and then we're going to identify what configurations inside those assets we need to keep monitored and keep controlled.
Then we're going to access our we're going to apply the configuration control sub processes, and this is where we ensure that all over configuration items are added and we can't modify them without proper proper authorization on proper change controls
on. And then we're gonna verify that all modifications we do make are added to the configuration management system as well as to the change management logs,
then we're gonna go through configuration verification than this is, uh, where we perform our checks to make that sure that our configuration management system says what is actually true about our configurations and the environment.
This is a relationship between the service management idea of things and the asset management idea of things. They both
are the core idea. They center around the framework of idle, and so they both share the use of the change management and the configuration management databases. So the configuration Management Daft database
it's service definitions out of the service portfolio, along with a collection of assets that we call an asset registry.
So we're gonna move into the validation and testing process.
And this is really where we ensure that all all of our deployed releases air meeting our customer expectations because remember that Idol is a customer
facing our customer focused
framework. Eso We really want to make sure that we're meeting our service agreements with our customers on. We also want to verify that operations are going to be able to continually support the new service just because we believed it theoretically, doesn't mean that the practical application will be truth
now. As I said before, this is kind of the difference between verification and validation. We started with our customer needs and expectations. And then in the strategy and design fees is we have turned those into a set of specifications, which our requirements.
We turn those requirements into, ah process or a set of processes to deliver a service or output a product.
Um, now the verification phase is we are verifying that our service or product agrees with the specifications that we interpreted.
However, validation is the idea that it actually meets the customer's needs and expectations as opposed to our own. So first we're going to verify, and then we're going to validate
so in the validation and testing sub processes were going to define a test model definition, which is essentially, how will
quality insurer releases? What are our metrics on and how will we be measuring those? These define specific test cases that will be used on will be updated as use cases and business cases evolve.
Then we're going to do we release component acquisition. This is really where we're going to gather all of the different components of the release and submit them to an initial assessment, which could be some kind of user testing, such as a B testing or other service validation.
Um, and this takes the output from our previous process of the release and turns it into information for our future strategy
When we do our release testing, we're gonna make sure that all of the components and tools that we use to deliver a release are also tested. So not just the service functionality, but also the way in which we deliver the service.
So the service acceptance testing is really about verifying that those conditions we have set forth in our strategy and through our client agreements were really meeting those.
And then we're going to get agreement from all of our stakeholders and forms of contracts and service level agreement
requirements, sign offs
that say that we have met and they are accepting. This service is as complete.
Once we go through that, we're going to update our knowledge center, which is the knowledge management process, and this is really where we want to gather and store the knowledge that we have built up over time about a service. Um, this could be certain configuration options
articles describing a user functionality.
and this is really, uh,
built up over time through all the other service management processes. It's not an isolated incident. This is simply ensuring that the information that we've gathered over time is stored and curated in something called a knowledge management system.
And today, a lot of times, our knowledge management system is a wiki
that is maintained by a company.
So we're going to do this so that we don't have to relearn information every time we want to go change the service. We won't have to go and
reverse engineer why we chose settings or added certain fields will just have recorded that information.
Now the knowledge management process doesn't have any sub processes because, as I said, all the sub processes of defining this information are spread out through the rest of the life cycle. Phases
eso Here's kind of the flow of how you would gather an update knowledge items for your knowledge management system. I'm not going to go through the mall, but if you'd like to take a moment to pause and just look through them. Um, this is really a good map of how you can
keep good information in your organization.
With that, we've come to the end of this video. I'd like to thank you for watching. And as always, if you have any questions, you can contact me on cyber harry dot i t my user name ist warder. T w a r T e r.