- [Instructor] All right, let's talk about
how we define the desired end state.
Where we want to take this, which is very important.
Now that we have a base set of requirements
and we've breaken those six things down
to their functional primitives,
and we understand the details around it,
where do you want to go?
Where does the business want to go?
And this is a very complex thing to determine.
So this is about you defining
where you are going, and the business is going.
Now keep in mind that this is going to be
discussions with humans, this is not going to be
looking at existing as is technology state artifacts
as you may have done in the requirements phase.
And ultimately, this is about vision,
this is about where things are going to be taken,
where is the company going to change?
Are they going to do acquisitions?
If so, what kind of companies are they going to buy?
So this requires you to kind of take
your technology hat off,
and put your business hat on
and really get into where the business is looking to go,
because you can't really define an architecture
unless you know where the future state is going to be.
So this can't be trial and error,
this can't be you iterating through this,
this is you creating a vision
and putting a line in the sand as to what that vision is,
and the important thing about that
is that you can become a partner with the business
and allow them to agree upon that fact that
this is the vision that you're moving forward with
as far as you defining the architectural patterns
that you need to put together to solve the issue.
And so, this is going to be a meeting of the minds,
an agreement between the techies and the business
as to where we're going as a business.
Now obviously, it may change at some point,
but we're going to try to get this right
initially the first time, because it's going to lead to
a more efficient use of any technology,
including cloud computing.
So again, we're at step two,
we're going to define the desired end state.
And within this instance we do a couple of things.
Number one, we deal with performance again,
in other words where performance needs to be
and what it needs to look like.
And so this is where we put details behind
what we did in the requirements.
Same with security, you know,
where are we defining the end state of security?
Is it identity access management, ultimately,
Cost/ROI, what is going to be the savings?
Now, we may end up costing more
for the first two years,
but we may save 25%, 30% of the IT budget
And basically defining what the end state can be.
This also allows us to, in essence, pre-deliver bad news,
in other words, if we're not finding the cost/ROI value
that we thought we would,
or security isn't able to live up
to the expectations of the business,
or performance is not going to be as good as we anticipated,
then we can deliver that news now.
And those things are pretty easy to determine,
you just have to look at where the technology is now,
where the technology is going,
and ensure that people are going to be
relatively secure in the fact that
there are certain limitations that are going to be brought up.
We have a tendency to look at technology
as something that's always going to deliver value,
that's always going to deliver improvement,
in cloud computing, just like any other technological space,
this is something that may occur in some instances,
may not occur in others.
And I'm more inclined to deliver bad news early
and then good news later than vice versa.
I think people need to understand
where the limitations are likely to be,
where the risks are likely to be.
This doesn't mean you have to be negative about it,
but this means you have to be realistic
in terms of what technology is able to do.
Next thing we do the logical architecture,
and the likely architecture.
Logical architecture being the fact
we're going to assemble the patterns that are there,
the fact that we're going to deal with this kind of network,
or the fact that we're going to deal
with this kind of security,
fact that we're going to deal with
this kind of application development platform.
Those sorts of things,
without binding them to a particular technology,
so this is not about you writing down AWS,
or Google, or any kind of databases out there
that have a name or a brand name,
this is about you picking a logical architecture,
which, by definition, is an architecture
that's not bound to physical limitation
or physical technology.
And then the likely architecture,
which means we are going to pick some technology.
In other words, we're going to look at the particular
databases out there that we're likely to use,
that doesn't mean we have to use them,
different networking things,
different application platforms,
different governance platforms,
and different security platforms.
And here we are going to put brand names,
and are going to put version names in there
as far as what cloud services we're looking to employ
to get or solve this architectural problem
with a likely architecture description.