Welcome to the Idol framework. Updated course from Cyber Eri I t.
My name is Daniel Riley. I'm your subject matter expert on the idol framework.
In this video, I'd like to talk to you about the service design phase, goals and processes.
The overall I'd be of the service design phase is to collaborate with all of our stakeholders and bring to light any ideas for how to deliver the service Any requirements that clients or other stakeholders might have
and to just solidify the plan, we came up with the service strategy.
Um, these are the process is that we're gonna work with design coordination, which is really about building the framework so that we can deliver these service's and service changes
Then service catalog management is about grooming and maintaining the information that we store on our service is Service level management is really about meeting our agreements with our internal and our external clients
about what type and the amount of service
we deliver service level availability and things.
we're gonna move into risk management from that because it is important
to understand the risks that your corporation or your company faces and how you're going to mitigate those. So we start that in the design process.
we're gonna move into capacity management because as you're designing a service, you have to think ahead to how much demand there will be on the technological underlying architecture of that service
availability. This goes back to the service level agreements of and maintaining those agreements and required levels of service is
now service continuity. Management might be more familiar to you as disaster recovery. Um, this is the plan and the ability to maintain business in the face of a disaster. And so we're goingto design and build that
into our service is from the beginning.
From there, we're gonna move into information security management topic, which is ah, big and a key that you have to bring in in the design process. You can't bolt security on after the fact
and separate from that we have compliance management. Compliance management is really about following the rules and regulations policed in your industry.
Architecture management is really about the technological structure, um, both in the present and in the future, and planning for the kind of flexibility that you need to change architecture
and last subject is supplier management. And this is where we really make sure that any materials we need from third party vendors are secured behind contracts. And we understand that they're meeting our needs.
So in design coordination, Um, like I said, the overall idea is to build a framework of consistent service design.
Um, And to do that, we're going to end up coordinating all of the sub processes that we're about to talk about under a design coordination manager.
Um, and they're basically gonna just ensure that there's everything consistent and effective. And every all of the resource is have the materials that they need.
from there, we're going to go into design coordination, support, which is all about co ordinating the sub processes. And resource is like I was talking about when they were going to go into the actual planning stage and the planning stage. We're going to break down the rough idea,
uh, of the service, and we're going to break it down into what steps actually need to be taken to implement that plan. Ah, lot of you will have recognized this is outputting a work break down structure
s So then we move into the coordination and monitoring phase. Eso along with the support phase you're going to coordinate all of the bringing together of the organizational resource is and pieces on dhe. Then you're going to make a review and decide whether or not
the design is even feasible. And you can look for early, uh, alternatives if you find some design isn't going to be economically feasible.
So in the organisational service design, this is where the Dev Ops really answers their side of How will they deliver
technology that will meet the needs of the service design.
Once we get all of that information collected, we put it into a package, and we submit it for a design review and then over Effect Crest for comment.
So the design review is generally with internal stakeholders directly related to the design team,
whereas a request for comment is generally more widely accessible either within the organization or even even externally in the part of
new service is that are like public facing service's.
So you're going to submit the design review package for a final review, which is then approved and
submitted as a request for change, assuming that never across for change,
uh, come back and have to be implemented. This initiates the actual implementation of the service. Once we have an R F C that's been accepted. This is really like a blueprint for the service operation.
So now that we have all of that information together and approved, we wrap it up in what's called the service designed package on the service design package really builds on the service level requirements from our service strategy phase, but it does so from a client point of view.
you take all of your
general requirements about operation and you formulate them from the idea of the end user, and you can usually find these done
of in in user stories and things like that.
So these are going to define essentially how we're going to fulfill the needs of the customer from the technical and organisational side. So we have
the the information from the Devil Team, which describes a blueprint for the technical side on Dhe. Then the organization will kick in from its side there
ideas of how they're going to fulfill the needs that they've listed from the client's point of view.
Now, all of this minute information is what gets stored under each service inside the service catalogue when we've talked a little bit about, you know, some other information that you want to store in there as well.
Uh, but since we're there, since we store all of this in the service catalog, we're now going to move into the service catalog management phase. And the point year is really to ensure that we have the most up to date and
most relevant information stored for each service
in a way that people can get to it and review it as needed.
Um, we're gonna make sure that always contains the most accurate information on all service Is that our operational as well as any other service is that have completed their design coordination and have,
ah, service designed package ready.
we're going to use this to inform all of our future processes. So as we decide to put a process or a service through a change, the first thing we're going to do is review the service catalog entry the service designed package for at that time,
so this doesn't have any sub process is officially, although you could argue that breaking out the service catalog management into some processes in your own organization makes sense, and I would probably agree with you.
This is the life cycle flow of service level management. Essentially, we're going to establish our terms with our stakeholders as to what service levels we can agree to.
Um, and what type of measurements will be using
from that? We go ahead and implement our plans, and these come in the forms of operational level agreements underpinning contracts and service level agreements.
We're gonna finalize these agreements that get signed off on what we believe we can deliver and what they're required. Deliveries are. And from that, we're gonna move into the management phase where we really oversee that we are actually delivering the results that we said we should,
And from there we're going to review all of those out pits on a regular basis and
established better service goals and more realistic requirements.
Such kind of a summary of that
we're going to gather the service requirements with the although the service level agreements that we've made throughout the requirements a manual see these as page load times or minimum activity amounts. Things like that in their requirements will get turned into service levels.
Um, and then we're going to monitor report on those two management.
The next step process for this is to
the actual maintenance of the framework. You can't just run it on autopilot. So you're gonna have to design and maintain the system on and then assign a person who actually goes through and apprise the service level framework.
And this can be a matter of making sure that you have templates for various agreements,
Um, or making sure that all of your documents and service materials are up to date.
So we're going to use this sub process of identification of service requirements.
Um, and this is really a list of customer desired outcomes.
getting these desired outcomes or requirements from the viewpoint, like we're talking about the customers desires
submitted for review so that we all know that we have the same understanding of the requirements.
The reason that we do this is we can catch any alternatives or anything that's not goingto fly when we try, because the later you get into a service development life cycle the Maur expensive, it becomes to decide the project was feasible.
So once we've got all of this, review them, We're going to get all of our agreement signed off
and again, you're gonna wanna have all of your s l A's ol ays. You seize all of those contracts signed off by their various owners,
and then from there, once we have sign off, we move into the sub process of monitoring and reporting. And this is going to be a common the theme throughout the process. He's in some process. Once we're set up, we always want to monitor that. Our levels are what we expected them to be.
And then we're going to want a report on that so that we can make adjustments over time
moving into the risk management phase of the risk management is really about measuring business risk and tolerance is, um
the overall objective is that it aims to inform the management of the company about operational risks. Um,
this is an official section
in the Idol framework, although it is discussed heavily throughout the materials, and it is expected to be detailed in their operational view in upcoming update
risk management support
is much like the other supporting sub processes. This is where we're going to define the framework that we're gonna use. And there are many risk management frameworks out there. And you're going to within that that frameworks going to specify how it quantifies the risks,
what types of mitigations that
finds acceptable and then your manager's air going to put in a certain level of risk tolerance. How much risk is the business willing to accept?
And finally, the business is going to name someone who's in charge of various risk management duties.
That person is going to perform an impact risk analysis. This is basically a quantification, a measuring
of the risks that we were discussing previously in the support section. So you use the framework at this point actually providing analysis. And the risk announce in this case is if a service were to go down or be unusable,
what effect would that have on the business?
Um, and how likely is it that ah loss of that service could happen?
this produces the business M backed analysis, which is going to be used
to inform all of our decisions when we're talking about protecting assets and things like that.
We want to make sure that we're protecting the most critical assets with the most
So after we've assessed the risk, we're going to assess our mitigation strategies. And this is basically just determining where we can mitigate some risk where we can lower our risk values and also, um,
defining whether or not we can accept certain risks.
Um, finally, we're gonna identify the owners of the risks and set up how they're going to monitor and report on the status of their risks.
Now, risk monitoring is the process of monitoring and reporting on those risks, but it also involves taking corrective action. Now we don't ever just want to take corrective action on our own because we see a problem. It's important to remember that we always want to
following change management
process, so we see a risk. We want to take corrective action. We would follow our change management process and take corrective action through the proper channels were necessary.
So let's move on engine capacity management.
A capacity management is really about ensuring that all of the I T levels that we have for each service are met or above our service level agreements on this has several sub processes. Well, ah, business capacity management
is kind of the strategic level of
Um, and the idea here is to translate the business needs of new customers, and ongoing business changes translate those needs into capacity requirements.
Service capacity management is kind of a tactical view of capacity management.
this is more about managing and controlling the actual capacity of service is. So If you were to be running a printing firm, service capacity management would be able to the prediction of how much capacity to print documents you need on any given day
and your plan on how you're going to meet that.
And again, you're going to wantto initiate summary, proactive or reactive
actions to ensure that you're making these agreements. But you don't ever want to do that in a vacuum. Follow the change mint of management process even when initiating you're proactive measures
and then component capacity management. This is really the operational level
of of capacity management. This is the actual availability and utilization of I. T. Resource is such a CZ servers or human resources, even
capacity management reporting is where we take these three phases of capacity monitoring and we provide management with information a za plan to see whether we're hitting our our utilization scores if we're over utilizing any of our assets
amore for under utilizing because Idol assets are a waste of money.
So he was kind of a visual just the way that those three stack on top of each other. The business capacity is the strategic. This is for your overall corporate managers. Then you have your service capacity management, which is the tactical level. These are the people that are making
on the floor business decisions
and then component. This is operational. This is your development team and your network team monitoring
moving from capacity management into availability management. These two are very similar, but they are distinct and they should be treated separately in availability. Manager, we're going to plan availability for service is based off of our impact analysis that we did,
um, and prioritizing the critical service is to make sure that we
have a plan for making those available first.
So that involves designing the service for availability right from the start. Um, you can't design a service, assuming it's going toe work on, then try to plan to make it available.
Uh, at some future date, it just won't work for you.
You're going to need to have a plan
upfront to deliver critical service is, um and to adapt those service is
and then you're gonna do availability testing, which is to take your plan and to put the system. It's supposed to do that. The service. It's supposed toe
guarantee availability for you. Put it under stress. And you you test to make sure that all of those mitigations and monitoring pieces that you've put in place are working.
And with that, we start monitoring and reporting
all Know all of our mechanisms to make sure that we're providing the availability that we agreed to in our service levels, Um,
and that we aren't losing or under utilizing any of our assets.
This is that again, just kind of a flow of the information that comes into the availability management process. We have our business impact analysis, the business availability requirements, but this is also where we discuss incidents and problems
other than security related incidents.
Um, which also do affect your availability. So you might include them in this data, but it's not generally the availability management's job to understand the ah security incidents.
But you do have things like configuration data,
Um, and it outputs. You're monitoring plans, your improvement plans, your resilience and risk assessment, which is kind of a strategic discussion of what risks the company couldn't could not withstand.
All right, So with that, we discuss service continuity management,
is about ensuring that your service can always be on. Even in the event of ah disaster, you want to be able to quickly recover business operations and provide some minimum level of agreed service is
now service continuity. Management support, like the other support roles, is about making sure that all of the staff is aware of what is needed and making sure that all of the relevant information that they'll need in the event of a disaster is quickly, easily accessible.
So make sure that the people are trained, they know what they're responsible for,
um, and they know where to get the information to, to properly handle their their duties.
All right, so again, we want to start with our continuity from the beginning we want to design it into the service. We don't want to try to figure it out after the service is fully baked.
Um, and this is going to list off cost justifiable continuity mechanisms because if a service is not critical
and the cost for keeping it at a minimum service level is
increasingly high. Um,
that might not be able to justify that cost to your boss. You may just want to shut the service down for a little while and save some of that money.
and this also includes designs for reducing the risks and the recovery plans in case things go wrong.
Now training and testing as we talked about making sure that the people were aware of their jobs, Um, the sub process of training and testing is really just make sure that all of mechanisms that you've put in place the people and the processes and the machines in case a disaster does strike
you don't want to figure out then if your plan was a good one
Finally, we're going to review all of our training and all of our plans to verify that they're still in line with what we perceive to be our risks today. Now this doesn't have to be done to frequently. Every other year seems to be a workable schedule for me
now in information security management. This has to start in the design phase. It must be included in every single phase is it's the foundation for Security.
and it's the executive management of the company that's ultimately responsible for the security of that company. Everybody likes to say that it's everyone's job to be responsible but ifs everybody's job. Then it's nobody's job, and that's why things aren't secure.
So it is the executive management
of the company who is responsible for making that company secure.
And their job with that is to ensure what we call the C. I. A triad. That's the confidentiality, integrity and availability of their assets on. And this is Bo Data. I t service is human Resource is a CZ well, aske laying customer data,
the sub crosses that we're gonna deal with. We're talking about information security are
ah designed for service security controls. So the security controls designed phase is about building the technical measures that you need to ensure the confidentiality, integrity and availability of the service's
and usually you won't get the trifecta. You'll usually be
Maur concerned with making sure that you have confidential information that's available to the proper people. Uh,
but then again, the the integrity of that information might not be as
critical. Or you might have confidential integer grow information that doesn't have to always be available.
so then we're going to go into our security training and testing, which again we want to make sure that our people are aware of what their responsibilities are and that they're well trained on the topics that they're going to be asked to handle.
Um, and we have to make sure that our people and our processes are all subject to regular testing.
Once we've got these mechanisms in place, we're gonna have incidents that we've started recording. And this is where the management of the security incidents that I was mentioning comes in.
The point of this process is really to detect that an intrusion or an attack is happening and try to minimize the damage from any successful attacks.
We're going to review our security over time,
using third party as well as internal processes. We're gonna make sure that all the measures we've put in place still match up with the perceived risks from the business side as well as changes in technology, hackers and
malicious computer people are
always advancing their technologies, and we have to make sure that we are reviewing our security processes and and staying and step with them.
Compliance management This is a separate
issue. As I've talked about compliance, management is about following the rules and regulations ah, laws that might come in to play in your industry. So if you work in a credit card processing industry where if you work in a law firm or a health industry,
laws and regulations that you have to follow when handling data and compliance. Management is really about making sure that we're meeting all of those.
Yeah, this just summarize that. Make sure we're in the price. Uh,
ensure I t service processes in the system's comply with enterprise policies and legal requirements. Now this wasn't official in the idol, however. Compliance management is expected to get an operational treatment in the upcoming update as well
that as I've said before, and I'll say many times, compliance is completely separate from security,
and they do not break this out into sub processes because it wasn't official.
Now, on to our discussion of architecture management.
are very complex, and normally an architecture will come down to a few people. A network engineer, a software development engineer on quite possibly, a database engineer is Well, uh,
but these provide the blueprint and the road map for future technology uses. We, um
as we build our service and as we move forward through service maintenance, um,
architecture can either be Ah ah boon or a bust.
So we're going to want to take into account all of our service strategy what it is we're trying to achieve and any technologies that are emerging or will be emerging in the next few years that we might wanna leverage on. We're gonna build ourselves Ah, plan so that we don't
get blocked out. We're going to build in the idea of moving towards those technologies in our current architectures as well.
So this is also not official yet, but it's referenced in the chapter on technology related activities. Ondas well worth reading because they give some very good advice on the process flow for architectures
and again because it's not official, they haven't broken it out into some processes.
But one thing that we should talk about you really can't get out of a discussion of architecture of these days without hosted on site versus offsite, an offsite hosting you might know as the cloud. So architecture management in the cloud has some special cases that you have to be aware out.
a lot of times in the early agent of the cloud, people believed that if the cloud provider was secure than you by proxy of using their service were secure as well on. That's just not the case.
Esso service architectures have to be flexible in the cloud. They need to be able to change cloud providers
without much change to the underlying architecture.
If you are reliant on a particular provider and you built in some code into your system
that is reliant on features, only they have,
and they decide to shut down that that feature or that company
Well, then you're kind of out of luck.
So we want our architecture to be flexible enough that it could run from multiple providers without much change.
Um, and then we also must account in terms of security for the proprietary information that we're using. Such a CZ are processing algorithms are customer data. All of these things were being stored and run off site on machines that we don't control.
So we need to account for that. Now, we do our database planning or data management
So with supplier management, really, we're gonna ensure that although our external supplier contracts are fulfilled and that they meet the needs of the business,
um, we're gonna make sure that the suppliers are fulfilling their actual contractor agreements with us. We won't just assume now this can be hard. In some cases, you'll have an easy contract where goods goods delivered
and you can easily tell if the wrong amount of goods has been sent,
um, and then their contracts for less tangible things, such as the number of good leads in ah lead lis.
So making sure that ah
a a a contractor is meeting their contractual obligation really comes down to clearly defined obligations.
So we're going to provide a framework like with all of our other sub processes and the the point of this framework is to provide the guidance standards and template documents so that we can procure new suppliers. And we have a process for evaluating them,
which is our next subset.
The evaluation of suppliers and contracts, which is really just tow, have a method by which we can choose between competitive suppliers for good at.
And it's not just an ad hoc decision.
Once we have a way of determining which suppliers we want to select, we're going to have a method for establishing a relationship with um and this is usually involved in, like contract negotiations, which are legally binding contracts between the two companies.
and these are mainly applied to really significant, uh,
contracts as opposed to everyday purchases.
Now we do have processing standard orders, which is a sub process specifically for handling your ordering of typical commodities under a certain level. So you might think of visas, office supplies or, if you know that you're going to always print 200 reigns
of than ordering a minimum of 200. Reams of that paper at some regular cadence would be part of the processing of standard orders.
Now, once we've got all of these set up. We're going to make sure that we review our suppliers and our contracts to make sure that they are still performing as we desire and that their needs they still meet our needs. If they aren't meeting our needs, we can divine some improvement measures.
or we can just go through the contract renewal or termination phase and in contract renewal or terminations. Subset,
um, we're going to assess if the contract is relevant and then choose to renew or terminate it as we need to.
This is kind of the life cycle flow of the supplier through our supplier management process. We source the supplier and then we move into supplier evaluation, which circles around through our development with that supplier relationship.
Um, we continue to look for other options on a regular evaluation cycle, and at some point in time, if we don't need the service or the supplier is no longer able to meet our needs, we can phase that supplier out
and choose a new supplier or shut down that part of the service.
With that, we've come to the end of this video. I like it. 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.