- All right, let's talk about creating the
final architecture, and what we need to do to get to
the ultimate solution, which is going to solve our problem.
So this is the final take on what your system should be,
and the configuration, and use of the technology.
So there should be no detail left out.
We need to go through the logical architecture,
the physical architecture, the technology we're going to
leverage down to the brand, down to the version,
down to the service, down to the reason,
down to security parameters, governance parameters,
all these things really need to be detailed down.
The reason is because
people who are going to change these things,
and that's typically not going to be you
as the cloud computing architect, are going to have questions
in terms of the details behind what you're recommending.
And this is the way in which you communicate that to them.
So in the consulting world, this is a huge deliverable
typically done by a team of 25 or more people.
They've come together, they've in essence come to
they've put together the recommendations,
what the thinking was and why they picked
the particular kind of technology, and so now this is
the big reveal as to where we're looking to go.
Now keep in mind, this is not going to be cast in stone,
that we're going to be able to recreate this a lot
over the next few years, and that the culture
in terms of one and done is not necessarily there anymore.
This is going to be an iterative process
where we're constantly improving the architecture.
So this is going to become a living document,
a living solution that we're going to carry forward.
So we need to have enough detail in here
so people understand what that solution is,
at least the first instance of it.
So this is the final push to a good
cloud computing architecture, and I think a lot of people
have a tendency not to put the information in there
that's needed for the people who are going to build it
to go off and build it properly.
I've found that when people leave things out,
assumptions are typically made,
and they're usually going to be the wrong assumptions.
So when in doubt, define it, bring it down.
Also, answer questions, and make sure people understand
what you're communicating to them.
So again, through our different steps,
we're at step four, and creating the final architecture.
what the system should do, not bound to the technology.
even though it's just the logical architecture.
The patterns that are there,
what performance characteristics does it need to have;
what the security system needs to do;
is there a centralized trust component;
the ability to manage, age, change, and push
governance policies into production;
the ability to bind this to DevOps, how that's going to look;
what the tool chain should be (not necessarily listing
but understanding that there needs to be a continuous
And all these things need to be in place
in order for you to create a good cloud architecture.
So again, it's as much detail as you're able to provide
without mentioning particular brands of technology.
You can mention types of technology, in other words,
we're going to use a database here in this,
perhaps a relational database, but don't list
a particular brand because we don't know enough yet
to really start making these decisions,
but we will in the next step.
Physical architecture is the selection of the actual
technologies and how they should be configured and tested.
If we do the job correctly within the logical architecture,
the technology patterns, at a detailed of enough level
so that picking the right technologies,
brand of technologies, type of technologies,
these could be cloud services or on-premise systems
or mobile-based computing systems, tens of thousands of
things can be part of a physical architecture,
we're able to pick those because we've defined
the logical architecture to such a detailed degree,
understanding the requirements and everything from
the previous steps we're defining here,
we're coming to pick a particular type of technology.
you'll find out that the physical architecture solutions
really kind of come to mind.
In other words, things that we've worked with
in the past and things like that.
I urge you not to pick these things with a bias,
or basically rewrite your logical architecture
so that it surrounds a particular physical kind of system
or physical kind of technology, but that you take
an objective view of what the system needs to leverage
from a pattern, and then once you do that, you can actually
pick the physical technology that's going to
meet the needs of that pattern.
In many instances, what I like to do is to have
different teams that deal with the logical architecture
And the reason you do that
is because of the innate biases there.
And so if people are actually picking the tools,
you'll find that their logical architecture
is likely to surround their particular biases.
You know, bias for a particular public cloud provider
or a particular kind of technology,
particular brand of technology.
So if you can, separate these into two teams, but again,
it's not necessary for you to do so,
but it is necessary for you to understand
the firewall separation between logical and physical.