I took time out a few weeks back to attend Edward Tufte’s One-Day Course on “Presenting Data and Information” and learned several new things and had several ideas reinforced by the methods and examples that Edward used. One of my favorite things that Edward brought up was encapsulated in this quote: “These are largely solved problems (displaying information); don’t get an original, get it right”. This of course immediately brought to mind the dreaded “Not Invented Here” syndrome and led me to think about how often I’ve encountered this in the IT world. On the other hand, innovation is terribly important and we take it very seriously at EMC - so how do you find the right balance of “solved problems” and innovation?

The point of Edward’s observation was that we often spend a lot of time focused on the container that we’re putting something into rather than the content. I’ve certainly been guilty of this while twiddling with a PowerPoint presentation at 3am in the morning changing fonts, colors, and finding stupid art that all really had nothing to do with what the presentation was trying to say. It was a real wake up call as was most of the content of Edward’s great essay “The Cognitive Style of PowerPoint: Pitching Out Corrupts Within“. So, what’s this got to do with IT? Well just like I get caught up futzing with PowerPoint fonts I’ve also been guilty of over-engineering IT solutions as an engineer and architect, and I know I’m not the only one. From trying to make components do things that they aren’t necessarily good at, e.g. let switches switch and routers route, or not accepting a solution because it only does 95% of what I want, even though the remaining 5% is largely icing on the cake not core functionality, or writing a message queue from scratch because hey, it’s cool. Focus on the content, boy that strips away a lot of the nonsense, doesn’t it?

When we were designing the Vblock a primary driver was to limit the non-recurring engineering that IT shops have to do. There is very little value in your engineers validating that NIC A works with Firmware B on Switch C when installed into Motherboard D and so on. And guess what, you’ve got to start that whole process over again when Firmware B’ comes out. The value is in having your engineers focus on the content, how do you integrate the solution into your security, BC\DR, compliance and monitoring infrastructure and policies. This is largely true of most stack solutions of course, I just happen to think the Vblock is more vanilla, more flexible, and what not, yeah, I’m a bit biased. You can extrapolate that thinking up to what runs on the Vblock, either from a software suite perspective or a development framework and so on.

Taking Edward’s point a bit further, the content is where you should focus your innovation. For EMC that content is our products and solutions and that’s where our Innovation Showcase helps us shine. If we spent a ton of time innovating on developing a kickass CRM system from scratch we wouldn’t have a ton of ROI to show for those efforts. If you’re a financial services company your content is how you get your customers to interact with you in new ways, how you get new products that are compelling to them in front of them, and how you ensure their information is secure and yet still useable. IT systems are enablers of these things, but they’re not the answer per se. I’d often hear, “If I install XYZ solution I’ll have a cloud, right?” in the early days of this whole cloud transformation movement. Hardware and software, IMHO, do not a cloud make, you need the processes, and policies, etc. to bring it all together. A solution like the Vblock is a cloud accelerant in my opinion, its goal is to help customers focus on the content. The best clip art and slide transitions aren’t going to get your point across, it’s all about the content.

Awhile back I got a call on a Friday night that is familiar to many consultants, “Can you be in City X on Monday morning?”¬† The program manager on the other end of the phone remembered hearing that I had a degree in Product Management and was eager to get me in front of his customer who was looking to transform his organization into one that managed infrastructure according to a Product Management Lifecycle (PML).¬† Now I admittedly view the world through PML-tinted glasses, but this concept had really piqued my interest.¬† The idea was a pretty simple one: convert his organization to be product-oriented and merge the PML with the IT Infrastructure Library (ITIL) framework and the Software Development Lifecycle (SDLC) that the organization was already spottily using.¬† As a Unified Field Theory devout I was hooked!

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.

I’ve been lucky enough to be in our industry for the last 17 or so years and I have seen all sorts of changes, as we all have. If I think back to my days as a research assistant at a university using the engineering lab Sparcs to create lab reports and pass emails back and forth with other researchers, I’d never have envisioned helping to design and run a system that would send out more than six million customized emails per hour less than ten years later.

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.