The customer, like most, was approaching the development, testing and management of their infrastructure through a number of siloes: people thinking about the long term strategy; another group concerned with the implementation of systems; a group that tested the integrated infrastructure; a group responsible for the daily management of the environment; and an organization dedicated to interfacing with the customer to understand their requirements (and on occasion their satisfaction).  Strategy, architecture, engineering and operations were divided across the organization with several silos within each knowledge area.  No one was incented to work together, no one had a vision of the entire infrastructure as a “system” and finger pointing was the order of the day during any outage.  Walking around the several floors the IT department was spread over there was an air of discontent, people bolted for the door at 5pm, at the latest, were largely disengaged and took pride in the walls they put up around their particular part of the organization.  Worst of all the business, their customer, was unhappy and questioning why they were spending so much on that black box called IT.

How do you solve this sort of issue through the wonders of Product Management you ask?  One of the great things about Product Management in my opinion is the sense of ownership that people working on a product have.  Whether your product is toothpaste, armchairs, or IT Infrastructure it is your product and you work hard to ensure that it is the best it can be, you think about it a lot, you constantly try to improve it, you become an evangelist for it and if you want it to be successful you try to see it as your customer does.  Sounds like great traits for an IT organization, right?  We worked together to instill the idea that the infrastructure was their product, identified their customer, actually spoke with them to understand their requirements and the perception of the current environment and defined roles and responsibilities for everyone in IT, mapped them to the PML and communicated it to the entire organization.  Pretty straightforward steps.

The entire infrastructure itself was seen as the brand, with product lines for Compute, Database, Storage, and Network.  Each product line had several products.  Within each product there were stacks, otherwise known as Tiers of Service.  Those stacks were made up of assemblies, or types of technologies, for example Platform (array), Interconnect (switches), Process (ITIL) and Resource Management in the case of the Storage stacks.  And the lowest level of granularity was components, or a particular instance of an assembly, again using the Storage example some components in the Platform assembly were Symmetrix, CLARiiON and Disk Library.  Certain assemblies were managed cross-product line like Process and Resource Management to ensure there was one coherent approach and system.

I’ll continue to share more about this particular experience in transforming an organization to use Product Management for IT and talk about tactical steps for implementing this yourself in future blog posts.

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.

In the early 90s IT departments, if you could call them that for most organizations, were necessary evils, a band of misfits who toted various cables and dongles and floppies around to who knew what ends. Today IT is at the heart of several large industries, the difference between successful, profitable businesses and those on the bubble. We’ve seen the industry evolve from sysadmins being a bunch of doctoral and master’s students to kids graduating from high school knowing how to program in a number of languages with a CCNA certification. When I try to imagine what the next 17 years will bring I’m mystified to be honest, the change has been rapid and amazing.

There are a lot of challenges facing us as we move forward as a profession. The interconnectedness of today’s market means that everyone wants access to everything, NOW. Cell phones are becoming viable compute platforms, they are fitting 32 cores on a chip and we have a pretty ubiquitous, fast fabric tying most of it together. At the same time there is more regulation now that pretty much the sum of recorded history to about five years ago. My colleague, Chuck Hollis, talks a lot about the need for a CFO of Information, I think he’s on the right track. But that new position requires tools for reporting and analysis that cut across the many silos that make up IT and the heterogeneous infrastructures supporting them.

No IT framework like ITIL or COBIT or MOF will act as a silver bullet, no off the shelf Resource Management system will give you all the insight you need, no new analyst acronym like GRC will encapsulate everything you need to worry about. A change in the way we design, implement and manage our infrastructure is required to ensure that IT continues to be a source of business value and not just a cost center, or worse the place were Information goes to become confused, lost and irrelevant.