Skip to content

March 21, 2012

Deployment Blocker No. 2: Think of deployment as a one-off

by Shelly Bird

The deployment of the new operating system is going to happen just once, right? So don’t plan for the longer term, beyond the immediate problem of how to roll out this major new system.

The penchant to treat deployment as a one-time event, instead of establishing a culture that welcomes regular deployments, and cultivating a healthy, willing pilot group, is a huge mistake on many levels:

  • Your culture will see deployments as one-time events to suffer through once every 3-5 years, and will resist the next one all the more
  • Your staff and users will be out of practice the next time you have to deploy a major change
  • Your image(s) will get exceedingly stale, out of date, within 2-3 months
  • The moment the image is laid down, it will start changing, and you are going to lose sight of the baseline you sought to establish if you don’t work to gain some basic control over when and how it changes.
  • Your user population will resist moving applications into the cloud, where they don’t directly install and control their configuration and updates.

Your baseline cannot be permanently set in concrete, or you will increase chances for:

  1. Attacks from the outside, which steadily weakens security:  hackers are infinitely creative, and you haveto continually evolve to respond suitably to those attacks
  2. Attacks from the inside, derived from a need for flexibility:  Users need to feel you will adjust when
    necessary to accommodate their needs—otherwise they will revolt, and there is
    nothing worse than an uncooperative user population

The Better Way:  Embrace inevitable evolution of your desktop configurations, and do what you can to lightly control it within a suitable range.  Start out by establishing regular drops of a new image with the latest updates embedded–often quarterly will work.  This gives everyone a goal to focus upon that is not too static nor too dynamic.  Push out with each quarterly image—which sets your new enterprise standard for the desktop, the new line in the sand–a delta package.  That package will implement the same updates and configuration changes to your existing desktops which have the older image, to bring them in line with the new baseline.

In short, set up a process that allows you to control your foundational baseline, a “waterline” you can flood across the enterprise.  This marks what you have decided is (for the moment) the ideal desktop base configuration, so when you test an application upon that baseline and it works, you know it has a high chance of succeeding in the production network.  Try wherever you can to change the culture to treat deployment mechanisms as an integral part of operations, a daily habit, much as is done today with public appstores.  Stand up small “point man” pilot groups (no more than 3-4 per group): actively cultivate and support these so you can constantly test updates in smaller, more controlled user communities.  Give them tender loving care, with a dedicated Help Desk staff to hear their complaints, and true responsiveness to problems they discover.  You do this because there is no reasonable way to emulate real life in the laboratory, and no better way to raise confidence, than to prove it works in the actual users’ production environments.

This is part of a ten part series of blogs “Top Ten Deployment Blockers”

Advertisements
Read more from Uncategorized

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Note: HTML is allowed. Your email address will never be published.

Subscribe to comments

%d bloggers like this: