In the last post
I showed you the first few pictures that I drew during my conversations
with folks that either want to know "why application delivery" or for
folks that have an application delivery infrastructure, but are only
doing XenApp. The next steps here are to now tell the story of
"delivery" instead of "deployment". At this level of conversation we
are wrapping in Citrix technologies like, Provisioning Server,
XenDesktop, XenServer, XenApp, et cetera. At the end of this conversation
the one thing that is critical is to get a design review/assessment done. That way you can make sure you
have a holistic view of your infrastructure and in the case of an
already existing environment you aren't carrying over any problems from
the old to the new.
The one thing I want to point out here is
that you need a good sized whiteboard. I like to keep all the drawings
on the board so that everyone can see the progression of the
discussion. What you will also find along the way here is that your
audience is going to ask a lot of questions. This is what I love about
whiteboarding. It really gets folks engaged and talking. You'll be
amazed at how easy the ideas and feedback will flow when you get going.
So
this is the point in the conversation that evolves into the "delivery" section. This is really where it starts to get
cool. I start by writing the word "DELIVERY" and drawing this picture,
but first without the words in the boxes. So just leave the boxes
blank for now:

So
in order to drive the point home about getting out the "old way" of
doing things (distributed computing) to more of a delivery architecture,
the above picture points out a few things. First, to centralize as
many of the applications and desktops as possible, with as few standard
images as possible close to your datacenter. From there you deliver
these dynamically, on-demand to end users.
So once you have the
picture above and you talk about centralizing and delivering apps and
desktops from a central location, explain what you mean. How? Easy.
In the first box closer to the "application icon" you will write in
"App WL" for "application workload". Here is where I explain that
what you now have is a standard catalog with a "master" image of all of
your application workloads (Exchange, SAP, SQL, et cetera) that can be
delivered dynamically to either your physical or virtual servers. Of
course, I'll tell you to virtualize as many servers as possible, but by
following this thought the rest of the way through you now have a very
highly efficient datacenter, even for those servers you can't
virtualize. Make sense?
The next box you are going to write in
"App UI" for "application user interface." For Windows apps this delivery mechanism will be XenApp. From here you can either
be "virtualized" on the server or streamed to the client and
virtualized there for mobile and offline users. For the Web
applications your delivery mechanism needs to ensure that the
applications are optimized for best performance, security and
efficiency. This delivery mechanism would be NetScaler. You can
better illustrate that concept by drawing a line across the App UI box
and on the top of the line writing Win and on the bottom writing Web.
The
next box you will label Desktop. Here is where I love explaining the
beauty of Provisioning Server, XenDesktop and XenServer. The whole
goal here is to separate the delivery of applications and desktops. By
just moving the desktops into the datacenter with all of its
applications hard-coded in we don't solve any problems. My best
practice way to do this is to deliver a pristine XP or Vista desktop
and then deliver the applications into that desktop from separate
application delivery controllers. You benefit from two things here:
- You eliminate compatibility problems
- You create a more stable, high performance environment
Finally
you will draw an arrow to a box labeled "PC" next to the user icon on
the previous drawing. This now illustrates the "delivery network" that
will be optimized to deliver apps and desktops to any user around the
world in the most efficient manner possible.

The
next thing here is to talk about management and "orchestration" of
workflows with the necessary tools. The tool to create those workflows
is the Citrix Workflow Studio that I highlighted in an earlier post.
Integrating the individual management consoles for the different
components of this type of solution with what you might already have in
place from HP, IBM, Microsoft, et cetera. You can illustrate that by adding
the already existing picture you drew like this:

Citrix
Workflow Studio will allow you to "orchestrate" communications between
all the different Citrix products more easily and will make it easier
to integrate into your exisiting systems management solutions.
So
now you have made your case and management has bought in. You now need
the next steps. The next steps involve what I like to call a "design
discovery". You could also call this an Infrastructure Assessment.
Why do you want to do an assessment? This gives you
a chance to understand the strengths of your current application
delivery environment, the risks and opportunities inherent in your
current application delivery approach, how your company strategic goals
map to a new approach to application delivery and to roadmap the
delivery of applications for both the short-term and the long-term.
I
hope this has helped you better formulate a way to get more buy-in from
management to expand or implement an application delivery
infrastructure.
Let me know your thoughts.