- [Instructor] Alright, let's talk about the problems
we need to solve.
Please understand that requirements are key here.
This is not about you invoking your will
or your biases on your architecture,
this is about you determining
what the business requirements are
and how those need to be translated
into a technology solution leveraging cloud computing.
Need to understand the as is state of things,
and how we're going to move to the to be state.
Need to understand the state of things as it currently is,
what we probably need to do to move
to a place that's going to solve the business needs,
and basically, inventorying the business needs,
everything that needs to be done.
Every piece of the business that needs to be automated,
and aspects of cloud computing
that can solve the problem.
So, understand we're moving from the as is state,
or as it exists, to the to be state,
or where we want to be solving the problems of the business.
And then we determine the technology to leverage.
Now, notice we don't pick the technology first,
we don't move directly into the technological solution,
even though that's a very tempting thing to do.
We all love the hype behind the technology,
and we all love to deal with modern
and state-of-the-art technology,
but this is not a matter of that.
This is a matter of you solving the business problems
that you're able to determine from the business.
So, what needs to improve?
Current state assessment as to what's going on,
what systems are there, what latency issues are there,
what problems you need to solve.
To be, how can it be improved?
What can cloud do to provide an improvement there, if any?
Future state definition.
Where things are going and how they need to be defined.
In essence, a conceptual understanding
of what the technology solution is likely to be.
Next we look at the technology.
We'll look at Infrastructure as a Service clouds,
Software as a Service clouds, security, DevOps,
and other things.
Can be IoT-based systems, edge computing-based systems.
And this is when we can explore the features
and functions of newer technology,
and what that technology's able to provide.
So, what we're doing is we're taking chaos,
typically systems that have not had a lot
of architectural discipline around them
for years and years and years,
and we're moving them to a good architecture.
That's going to be a difficult thing to do.
You have to remember that you're dealing
with cultural issues, typically people, processes,
and technology, and ultimately,
how they're going to accept the change
that a good architecture is able to bring
to the organization.
So, you have to remember that if we're moving things
in the cloud, or at least that's the understanding
of where things are going to be moved,
that your ability to, kind of, take requirements
and take technology that typically has been placed
around a system that's very chaotic
and then moving it to a well-structured,
well-organized, well-planned architecture
that enables cloud computing is going to be, ultimately,
what your objective is.
So, we're moving from the current state to the future state.
as is state, to be state continuously improved,
and we need to understand that the to be needs
to be designed, so it has to be planned.
This is not about us determining
what we think the to be state should be,
this is moving from the current IT assets
and the requirements into the initial design, or the plan.
From there, we're able to pick a technology.
Then, moving into a continuous improvement state,
we're able to take feedback and rework
and then move that back in the design,
and understand that this is going to be continuously improving
over time and that we're never going to be done
with our cloud architecture.
Keep that in mind.
This is about your ability to set up a process
so we're able to provide feedback
to the architects, to the developers,
to the people who are doing the systems planning
as to what works and what does not,
and ensure that we're always thinking about
and rethinking about how we're going to
continuously improve the system.
And ultimately, that's the goal,
and therefore we need to figure out the metrics,
the ability to understand or measure ourselves
against the requirements of the business.
How well is the technology living up to the needs,
or the requirements, the needs of the business?
Need to test the technology to ensure that it's capable
of doing what we think the technology's able
to do the way it's being sold.
So, performance testing, stability testing,
security testing.
All that stuff has to be built into these processes.
The ability to evaluate the technology
based on its testing results and it's ability
to live up to the functionality.
And then, finally, your ability to implement the technology,
or deploy it and put it into production.