- [Instructor] So in the home stretch here.
And what's important here
is that you'll be able to find a step-wise path
these particular sequence of steps.
This means that this is, in essence, a jumping off point
and you may find different steps that you need
for your particular business
or your particular technological need
or architectural need.
Things like that, and that's going to be fine.
So what I'm giving you here
to cloud computing architecture and make it your own.
And so as you go through these steps,
think about how it's going to apply
And what you can remove as well.
There's aspects of this that aren't necessarily mandatory,
but we are providing general step-wise,
general advice here in terms of
how you're going to leverage this technology,
this architecture, this approach, this methodology.
and we're going to talk about that in this particular video.
In other words, what's the target that we need to get to?
Need to define where we currently are,
our "as is" state and our "to be" state.
Number three, mapping the "as is" to the "to be".
what are the gaps, what needs to change,
and what step-wise needs to occur
And then create the final architecture.
In other words, once we know where we been,
where we're going, and the gap between the two,
we create a final architectural solution to get there.
So ultimately, defining the requirements
means that we're dealing with a business process,
data, security, governance, performance, and cost.
And these are good checklists to use
if you're going through the business.
And so what you're going to need to do
is figure out, in essence, in some cases,
map the processes that are occurring
Ultimately, this is important because
it allows you to do a couple of things.
Number one, understand the business,
and also re-engineer a few of the business processes
Second is understand the data.
This is probably one of the most important aspects
of you defining your requirements
for your cloud computing architecture.
You need to understand the metadata where it exists,
who owns it, the security parameters around it,
and basically all aspects of the system
that are going to be important to you.
And can't stress that enough,
that if you don't understand the data
you're going to have a poor foundation
for your architecture and your applications.
Next, dealing with security.
Security is systemic to the architecture.
It's not something you bolt on
So with each of the phases of the architecture,
you need to figure out how you're going to approach security
the enabling technologies,
such as identity access management and encryption services.
How are you going to deal with things
that are going to be coming down the road,
how you're going to monitor
and have a proactive security solution.
Next is governance, how you're going to deal with
policy management, the ability to build policies
Both costs policies, the ability to deal with
cloud based systems that cost money.
the ability to put guard rails around
how developers leverage cloud resources.
All these things need to be defined
in that part of the architecture.
Next, performance, are we going to meet
the performance expectations of the business?
where we need to go upscale with our computing resources?
around commodity based computing?
In other words, what saves us more money
but may have some exposures in terms of
performance bottle necks that may happen from time to time.
And then finally cost.
Cost is always going to be an issue.
While people automatically think
that cloud computing is going to be less costly
than traditional computing,
that is not always going to be the case.
And so we have to figure out the architecture
that we're improving the cost optimization
for these particular components.
And that means agility, that means
actually operational costs,
that means avoiding CapEx expenditures,
and getting into these very complex business scenarios
to ensure that we're actually adding value
in moving the company to the cloud.
So step one, define your requirements,
and step two, deal with business processes,
data, security, governance, performance, and cost.
And if you go through these six things
and you break these down to the functional primitives,
and actually look at how they relate to requirements,
you can't go wrong.