First, let me preface this post by saying that I despise Powerpoint. Not that I’m against Office, just Powerpoint for presentations. Why? they aren’t engaging, no one remembers more than 20% of the information in those anyway, and if I just wanted them to read something I would have sent an email. I work to engage people in an interactive dialog when I talk about application delivery and virtualization.
I want to share with you the kind of conversations that I have at every initial meeting with potential clients and even clients that already have an application delivery infrastructure. The reason for doing this is to help you to build your case to your management team for expanding Citrix Application Delivery in your environments sans Powerpoint like I do when I’m in front of a client. I’m a big fan of using pictures to share my ideas, thoughts, and to solve problems and I’m going to share with you how I do that for application delivery and virtualization. Check out one of the greatest books on this subject by Dan Roam.
I have many versions of my whiteboard conversation depending on the level of meeting I’m having (CIO, Network Architect, Desktop Operations, etc) but they all start pretty much the same way, I ask questions. Before I stand up to draw anything I’m asking questions around priorities, challenges with apps not meeting metrics, etc. Now I would expect that since you are on the inside of your organization you wouldn’t have to do as much discovery as I do, so build upon what you know and do your due diligence.
I’m going to start at the beginning of my whiteboard so for those of you who don’t have an application delivery infrastructure you can see how you get started. For those of you who have an application delivery infrastructure and you want to expand it, this will show you where to start and go from there.
The one thing that is true and constant in today’s environments is that business runs on applications. When access to or perfomance of applications is compromised, top and bottom line results are affected. We know that for our companies to be successful, we must ensure that the business’s applications are accessibile, reliable, secure and fast. This is where I draw an easy picture:
As we all know our companies are facing some pretty strong forces that are separating users and applications. These forces are dynamic and very volatile. They increase the challenge of ensuring users can use the applicatios they need when they need them. Then I draw this picture:
So what are those forces that are driving users and applications apart? They range on the user side from globalization to e-commerce and on the application side from consolidation to new application types like .NET/Web 2.0/Java etc.
The way we have built infrastructures in the past are no longer viable models today. They are too rigid and don’t adapt well to rapid-fire changes in the business world. One common experience among the majority of clients I talk to is that when they want to make applications available to end users they encounter multiple levels of complexity. To get the application rolled out they have to engage the server group (who are worried about power and datacenter space), the network group (who are always thinking about bandwidth and traffic), the security group (who are always thinking about the risks and the vulnerabilities), the systems management group (who try to make it all fit together), and finally the desktop group (who is ultimately responsible for supporting the clients). This is what we call “distributed computing”. This siloed approach is easy to organize people by their technical disciplines, but it seriously makes things harder to get done in today’s fast moving world. So while I explain that last piece I draw this picture:
So as you can see by the line labled “silos” through the Servers box, this is what we are talking about above. An unintended consequence of incremental investment in these fucntional silos is that your infrastructure becomes too hard to change. What you have then is an infrastructure that lacks scalability and it’s inflexible. It is also costly to implement and maintain and finally changes to this kind of infrastructure or the applications can cause unplanned consequences in this now weak environment. In the end, you might have solved the issue at that point in time, but your infrastructure is still so rigid that it can’t change fast enough to meet the business needs. I can tell you from first hand experience that trying to optimize every silo I outlined earlier will never increase your company’s agility. As you can see I have a down arrow drawn and labeled it Agility and I have an up arrow that is labeled TCO. That TCO number represents per user costs. Making changes in the current environment requires additional investment.
Ok, so I showed you where the majority of folks are at, now you have to visualize how to pictorialize your environment in as simple pictures as possible. In the next post I’ll show you how to take this part to your management and really “sell” the idea of application delivery to them and the rest of your company.
