- Now let's continue our architectural
step wise journey and talk about mapping
as is to to be.
So it's important to map where you are
and where you need to go.
This is an important step for a couple
of reasons. Number one we need to have
a meeting of the minds with the business.
And so understand where we're going from
the current state to the future state,
what it's going to cost, who's going
to be involved with it, how many
resources are going to employed, what
risk is there and what kind of
things that they can do to help you
move into the the right cloud computing
architecture.
So as is and to be are traditional
architectural concepts that are
helpful here as well. And the reason
we need to define as is because people
will know what the as is is and
they know what the to be is, what
it's likely to be as the solution
that we're going for. These are terms
that are both technically and
business related. And so we like to
use them and the fact that people are
automatically get or understand what
as is and to be means. And they're
very helpful to us understand to
figure out where we are, where we're
looking to go and therefore we can
define how we're going to get there.
And once we know where we're going, the
approach or a solution to get there is
relatively straight forward.
So again we're moving to Step 3 mapping
the as is to the to be. And a couple
of things here. We have the current
state, data, compute, storage and
application. We can add governance
to that, we can add any number of
things that are going to allow us
to decompose the existing states
down to a primitive level we're
able to understand of both the
general things and the detailed things.
Need to understand the data including
metadata, properties, specifications,
security, governance systems, things
like that are bound to databases and
bound to data specifically.
Next we need to understand compute.
What computer we using on premise
and maybe some cloud based systems
some hosted based systems, managed
service providers, co-location
providers things like that. What
they are, the version name of
the processors, the platforms
they're leveraging. What versions
of the platforms are they leveraging?
Operating systems, what networking
infrastructure and backbones are
there? All that stuff needs to be
documented including storage
systems. Are they using traditional
storage packs within the data
centers such as EMC and others and
if so where are they located?
What about security around them?
How are they communicating with
the compute systems? Then the
applications that are there.
Probably most important document
the applications, do triage of the
applications. How were they built, when
were they built? Who built them? Why
were they built and what functions of
the applications are there that you need
to consider. Then future state which is
where we're looking to go. What is our
data state going to be? In other words
if moving to the future state to
the improved state which is going
to be meeting the requirements of
the business. Are we moving to
new databases in the cloud? If
so, which ones are they? What
versions are we looking to
leverage? Why are we making the move?
Same for compute. Are we moving to
new processors in the cloud? Are
we just relocating to what are
called platform analogs? Are
the ability to find replicants of
the existing on premise platforms
that happen to run in the cloud.
Different choices there. Are we
leveraging the same things that
are cloud native? Or are doing
just lift and shift kinds of
movements into the cloud?
Storage analogs. Are we leveraging
object based storage, block based
storage, again are we replicating what's
on premise currently or are we upgrading
the storage or changing the storage to
something that may be more efficient such
as cloud native storage such as Amazon's
F3, block storage, elastic block
storage, things like that.
And then finally the application which
is probably more important. Are we
going to modify the application to
leverage cloud native features? In
other words we may do that for
performance reasons or security reasons
or the fact of the matter is we want
to leverage identify access management on
the particular cloud brand that we're
migrating to. If so we're going to have
to change the code of the application. Are
we willing to go through the pain of
changing the application perhaps
rebinding it to a new database or
are we going to take an easier way out
which may be the right choice from the
business point of view where we just
migrate the application to a platform
analog in the cloud, lift and shift and
do the same thing with the data.