Archive

Posts Tagged ‘project management’

Book Review: Enterprise Network Testing

May 6, 2011 1 comment

For my next trick, I am going to review another Cisco Press book titled “Enterprise Network Testing”.  I think I can sum this up in two sentences:  “Holy Crap!” and  “This book has PLENTY of cowbell!”.

Now I am not currently a network guy by profession, but if I was, this book would be on my desk with copies on my teammates’ desks too.  It is literally THE blueprint for how to test your network.

The journey into network testing begins with a discussion on why you need to test your network.  Most people only think of one or two reasons.  This book provides a few more to help you make your business case.  BTW, the authors make it very clear that testing your network is not a one-time event.  Testing should be done whenever changes are made, for compliance, introduction of new technologies, etc.  In other words, plan on testing regularly.

One area where this book and I completely agree is where testing should first take place: in the lab.  There is whole chapter devoted to lab strategy.  Topics covered include staffing, facilities planning, test methodologies, power, and more.  I must say that I was surprised at how good this chapter turned out to be.  Most books give basic guidance on lab setup, but like I said at the beginning of this review, this book has plenty of cowbell.

So now you have your lab setup, what are you going to do?  Simple, read this book because it provides guidance for “crafting the test approach” (actual chapter title).  Briefly, this chapter discusses several reasons/objectives for testing and how to craft your strategies to set you up for success.  This includes setting your test targets, what tools are you going to use, writing a test plan, allocating resources, etc.  It’s a very well thought out approach.

Business case approved? Check.  Lab resources allocated? Check.  Test plan created? Check.  Great, now go execute your plan.  Need help?  No problem, this book will walk you through a sample lab setup, finding the appropriate tools, and a few different methodologies for measuring different network characteristics.  This is the point in the book where the authors stress the need to understand what you are testing, the tools you are using, and how to interpret the results.  In other words, if you don’t know what you are doing you will not be successful.

Speaking of knowing your tools, this book does a credible job discussing network toolsets that are available for free and for purchase.  Even non-Cisco products are covered which is something I am not used to seeing in a Cisco Press book.  Usually, these books are oblivious to other companies’ products.  Kudos to the authors for being thorough.

The next six chapters are where you will find plenty of test case examples.  There are individual chapters devoted to six types of testing.  They are: Proof of concept testing, network readiness testing, design verification testing, migration plan testing, new platform and code certification testing, and network ready for use testing.  They are written in a case study format and are quite readable.

Nerdgasm time.  This is where the book gets hairy…Are you too lazy to develop your own plans from scratch?  You want to cheat?  Just borrow the DETAILED test plans that are in the next seven chapters.  There is enough meat here that Cisco Press could copy & paste into a shorter book to sell.  We are talking over 200 pages of test plans covering seven areas.  That’s a lot of cowbell!

The book ends on a high note.  Since you went through the trouble of setting up a lab, why not use it for training/learning purposes. Step-by-step instructions are provided to setup a lab. This chapter may not be useful to a large number of folks since the equipment covered is pure Cisco, including UCS.  In fact, many of the directions provided center around setting up a UCS environment. I happen to like this chapter because one of my last major implementations before joining VCE was installing UCS for the organization at which I worked.  Sort of brings back memories.

To sum this review up:  If you are in the network field, you need this book.

My First 60 Days at VCE

March 3, 2011 5 comments

Everyone seems to post a “My first 30 days” type article so I figured I would be lazy and wait 60 days.  What’s it been like?  Crazy.

 

Let’s start with some organization structure.  All the glory hounds, ahem, people you probably know are in some sort of sales/services group.  Names like Aaron Delp, Kendrick Coleman, Steve Chambers, and Ken Hui come to mind.  Those guys are customer facing.  They get all the training and they do all the partying, er, traveling.

I, on the other hand, am under the umbrella group known as Platform Engineering.  This is the development side of the Vblock. It’s doubtful that I will ever meet a customer unless it is at a trade show or a customer advisory board meeting.

Platform Engineering itself is broken down into three general groups: hardware, mgmt. & orchestration software (think UIM), and virtualization.  I’m in the virtualization group, where we are responsible for all things VMware in a Vblock.  My specific position is Principal Program Manager, which basically means I am a project manager.  I am also the technical relationship manager between VCE and VMware.  Notice I said “technical”.  I am not involved in the business relationship.  Instead, I coordinate with my VMware counterparts to get the VMware technical resources folks at VCE may need.  Part of this relationship management requires being the keeper of roadmaps, license keys, grantor of access to partner websites and materials, and so on.

Now every development company has their own version of a product development lifecycle process.  It just so happens that VCE formalized its process a few weeks before I started.  Since my project was the next to start, it gets to beta test the new process.  So what is my first project?  It’s a doozy.  I am managing the development/integration of the next major vSphere release into the Vblock.  It’s so high profile due to it being the first to follow the process and it’s subject matter (vSphere) that more than half my project team is made up of observers.  I would categorize project team members into three groups: folks with deliverables, folks just watching to see how the process goes, and folks who just want to be aware of our vSphere work.

You would think that it would be as simple as installing the next release and saying it’s done, but it’s not.  Decisions have to be made about what features to turn on/off, how they are to be configured, upgrade processes/procedures, etc.  It really is a lot of work.  Then all that has to be tested and documented.  At the same time, sales/services (including support services) staff needs to be trained, and marketing materials need to be developed.  All that has to be tracked and coordinated and that’s where I fit in to the picture.  Yes, I herd cats.

It hasn’t been easy because I don’t really know who all the players are.  Every week I get at least one email telling me I left so-and-so off the project list.  Part of the issue is growth (people changing positions), the other is based on organizational structure.  Some groups in VCE have names that sound like they perform internal work only and wouldn’t be interested in vSphere.  Nope, many are actually customer facing and perform technical work.

Once the first project is done, we (meaning myself and other project mgrs. in VCE) will have a better idea how things will flow.  Kinks in the process will be worked out, roles will be determined, etc.  It’s nothing that other fast growing companies haven’t experienced themselves.  In that regards, I am lucky because a number of people I am working with came from fast growing startups so I have their experiences to draw upon.

What else has happened in the first 60 days?  Acadia became VCE, which required all docs, websites, presentations, business cards, etc to be updated.  EMC released VNX.  Cisco released new UCS firmware.  VCE became participants in some of VMware’s beta programs.  The list goes on.

 

One last item to note: my last post touched upon the personal reasons I joined VCE.  Lisa Caywood said I was giving myself a personal stretch assignment and she was right.  I referred to myself as not very socially adept.  What I really should have said is that I do not get personal.  I can walk into room and strike up a conversation with no problem.  You want to talk computers, politics, or economics; easy-peazy.  Just don’t ask me if I am married and I won’t ask you.  I don’t know why, I just don’t get personal.  It’s not that I don’t care, because I do.  Heck, I don’t even know my wife’s favorite color, favorite song, etc.  Well I wanted to change that.   And I have.  I know the marital status and family setup of my immediate co-workers.  I even know some of their hobbies.  When I talk to people, I ask how they are doing and I mean it.  It hasn’t been easy getting into the habit of doing this.  My monitor is adorned with Post-It notes reminding me to be personal.  The good news is that I am starting to ask these question without the reminders.

I also mentioned my desire for order and control; two things I do not have at VCE.  I’m getting used to it now and it’s spilling over into my home life.  This is a positive because I don’t get annoyed as much when things are out of place and I don’t get as frustrated when things in my personal life go awry.

I am still working on recharging myself.  I didn’t expect it to be instantaneous and it hasn’t.  I am getting there though.

Categories: Life Tags: , ,