Now I know Newman is heavily biased on the “Infrastructure” part of his world, but I come from a little town where you didn’t buy stuff you couldn’t use effectively.  You call it infrastructure, we call it “stuff”.  We drive pickup trucks not because they’re cool but because they have utility: as a snow plow, hauling trash, parades, hay rides and general gittin’ ’round.  All of that while laughing at people who buy fully loaded dualies for commuting.  It happens.  I could never see myself writing an outsourcing contract that lost money just on this experience alone.

Making the connection yet, James Burke?  In my experience, these outsourcers get into trouble because they forget three things…

1. What you’re supposed to do with all that infrastructure
2. HOW to do it, and
3. How to write a contract to support it

Newman touched on the third part there, which I’ll get to in a moment but the first two just demand more air time immediately.

I’ve seen too many outsourcers allow themselves to get bogged down trying to use every single feature on some gear without any focus on why they’re doing it (they get pushed around a lot, I have noticed).  Perhaps the inclusion of some buzz words in the proposal closed the deal, but at what cost?  Some manage to stay afloat or get ahead but most don’t have the skilled talent on hand to pull it off.  It is tough staffing the top 10% of industry folks on every job.  90% of the time you have lesser talent.  The solution here is to frame up the services and support you will deliver in light of your available talent, ability to standardize complex activities and the strength of your plan-B should things go wrong.  The customer should NEVER see the outsourcer fall down on service levels.  It is death to your business.

On the other hand, too many of them ask “what’s a service level?”  That’s the contract conundrum.  If they could teach themselves to write better service level agreements tied to real world metrics these problems would be trivial to solve.  I’ve seen several contracts where the language for change orders and “extra” services conditions is longer than the actual service definitions for what WILL be performed!  What the heck are you people thinking?  Put a box around what you’ll do and with what equipment you’ll do it based on a real need from the client.  Write that need down.  Put equitable performance penalties around both sides of the deal and manage to the service level, not the contract.

I know that last part sounds contradictory but if you can maintain your availability, ticket turnover and performance metrics fewer people are going to ask you to do things that “uh, sorry, we don’t support”.  Know what your limits are, use the equipment the best way you know how (don’t stretch it) and let your people find their way to meeting the requirements.  The bottom 90% are still some pretty damned smart folks.  Left alone to establish repeatable methods and standards they perform exceptionally with little waste effort.  Yes, Average Joe can pull this off with some basic controls.

All that, and what Newman was saying.

On the other hand you people can continue to write contracts that demand 75 hours a week from your best resources just to break even.  Knock yourselves out.  Meanwhile I need to take a look at a new truck with my father.  Should be fun.

I’d like to present one solution that has been used to good effect in the past: the introduction of a new, and necessary, tier of storage to the service catalog.  I think this applies not just to outsourcers but anyone who runs their environment in a service provider mode.  A lot of customer I interact with complain that the performance of their Tier 1 storage is suboptimal and that their backups never finish on time, or aren’t validated, etc.  While hardly a novel or new solution appropriate archiving is the answer to these sorts of problems, and if you view it from a TCO perspective you can gather a lot of financial evidence for the executives on why it should be implemented.

I encourage my customers to think of their production data in terms of two classes, this is the highest level of data classification in my opinion, Operational Data and Reference Data.  Operational Data is that which the enterprise uses on a regular basis to run the business, the key is understanding where the cut-off is for “regular basis”.  Reference Data is that which is helpful to have around,  you might use once in awhile, for a quarter close or year end analysis, but which is ignored on a daily basis.  Reference Data takes up valuable Tier 1 storage, backup bandwidth and storage, and as a result can lead to blown SLAs.  The appropriate archiving of this data provides an opportunity to right-size the environment, delay the purchase of additional Tier 1 arrays, streamline the backup flow and improve Service Levels by administering data according to its value to the business.  The creation of an Archive Tier(s) provides an opportunity to deliver a necessary service to the customer while also enabling the provider to structure it at an improved margin.  Customers will want to archive Reference Data when they can link it to improved Tier 1 and backup performance, driving archive utilization and with it the improved margin while at the same time improving the margin on the other services due to fewer SLA misses and a lower administration cost.