Watch Diane Bryant, Intel CIO, talks about the cash machines in data centers in this press breifing. Haven't heard about the amazing cash machines for your data centers yet?! Better check it out now: Installing Cash Machines in your Data Center

Last week I had the opportunity to attend the CIO Forum held in conjunction with the Insight 2009 Annual Conference in Orlando, FL.  While being held adjacent to Disney’s theme park, the theme of this event was appropriately titled “Vision Voice Value”.




I spent two days discussing best practices, sharing lessons learned from Intel IT and comparing notes and strategies with leading CIOs, IT Directors, Managers and Administrators in the Health Care profession.  Our focus? ways to deliver and articulate the business value of IT. I had the opportunity to:



• participate in a roundtable discussion of ~15 Health Care CIOs titled “The value of IT in improving financial performance”
  
• present to 50-60 CIOs on the business value of server refresh
  
• present to 20-30 IT Directors and Administrators on using the Xeon ROI tool as a way to justify server investment




One of the most thought provoking questions at the CIO roundtable that has stuck with me is … “How does your CEO (or your business customers) view IT?”  … as a cost center (necessary evil) or as a value center (strategic enabler).  While no one directly answered this rhetorical question, it was clear that our collective mission is to migrate IT from cost center to value center.  This migration will not be immediate.  It happens over time.




To enable this transformation from cost center to value center, we concluded that the accountability remains with IT, as IT professionals and CIOs must individually and collectively demonstrate business value through our investments and establish are relationship of IT predictability, trust and credibility with our business partners.   These are core themes I have seen very visibly inside Intel IT as I began my journey to the center of IT a few short months ago.




My second observation from this event reinforces some personal experiences I have had working with many other IT professionals in the past several months.  With the global recession and it’s impacts to capital funding, the need to justify IT investment is greater than ever – and the competition internally for capital $ is very high.  We may never go back to the way it was.  We have seen this inside Intel IT’ organization as well and as a result, created at server refresh savings estimator tool to share what we learned in justifying our investment a proactive server refresh strategy in 2007 and staying committed to that investment in 2009.




I demonstrated the server refresh savings estimator tool at the event to both the CIOs and IT Directors / Administrators and the feedback was very positive (“session was well worth my time”).   Prior to the event, I also had the opportunity to work with Deborah Gash (CIO for Saint Luke’s Health Services) and her staff.  Debe provided a glowing endorsement of the tool (Thanks Debe !!) after demonstrating the business value from a project already completed and the in intent to use it for several future projects. I invite you to learn more about why we created this tool and how to use it.  If you have a question or want to give us feedback on how to enhance it – just let me know with a comment on this blog.




My final thought comes from a blog written by Don Sears at eweek.  Don discusses about the need for IT to be right, accurate, credible and trustworthy is so important whether you are working inside IT or with IT.  Credibility and Trust is something that is hard to gain and easy to lose … so it is easy to understand why being right is key to working with IT.  Getting it wrong can have huge consequences.




Join us at IT@Intel and share your insights on our shared journey to transform IT from a cost center to a value center for business.  I look forward to hearing from you.





Thanks, Chris

If you like this, follow me on twitter

I hate fixing the roof.  In fact, I have been postponing a roof repair over my garage for about 2 years now.  I recently read an article by Peter Kretzmen titled “IT, The CIO, and the Business Need for Roof Projects” and realized that while I can put off my roof repair, IT may not be able to postpone routine upgrades. 

For businesses, technology refresh is a standard business process (ie a roof fix).  The question for IT often boils down to WHEN I should upgrade, not IF. Why? … because hardware technology ages, maintenance costs rise, and software solutions can become unresponsive or obsolete as business needs change, user needs evolve and new technology and software become available. In this economy, cost is king and reducing IT costs has clearly become a critical imperative.

My colleagues in Intel IT recently conducted two separate and independent studies on how frequent we should refresh our PC fleet and data center servers.

PC Fleet Management:  John Mahvi and Avi Zarfaty from Intel IT recently wrote a paper titled “Using TCO to Determine PC Upgrade Cycles”.  The conclusion of this analysis showed that a 3.5 year refresh rate was optimal for total cost management in our IT environment.  Despite the fact that delaying PC refresh this year was initially seen as a cash conservation approach, the analysis showed that not refreshing older PCs increased the business’s overall costs.  As a beneficiary of PC refresh (I got a new laptop a month ago ), I can also personally attest that my productivity has gone up.

Data Center Efficiency:  Matt Beckert and Diane Boyington of Intel IT recently published a paper titled “Realizing Data Center Savings with an Accelerated Server Refresh Strategy”.  This paper discusses Intel IT’s movement to a proactive 4-year server refresh cadence in 2007 and illustrates both the long term savings (up to $250M over eight years) and immediate benefit to the corporate bottom line ($45M saved in 2008). After plans to refresh our servers was slowed earlier this year to preserve capital funds, a re-assessment was done that showed that Intel IT could save $19M by refreshing now vrs waiting until 2010.

Just like you shouldn’t sleep in a house with a leaking roof … it is prudent to not let old hardware create a hole in your IT budget. In today’s economic environment, Intel IT can’t afford a leaky roof and so we are moving forward with proactive business client PC and Server refresh, proven approaches to reduce TCO and boost business value.

Chris Peters, Intel IT

twitter @chris_p_intel

Let me begin by way of introduction - I am a strategic financial analyst with Intel IT Finance organization focused on data center strategy and efficiency efforts.  This is my maiden voyage into the world of blogging, so I hope the topic is relevant and interesting to the audience.

Similar to many organizations, Intel IT is focused on constantly improving the cost of keeping the business running while not sacrificing the level of support required by customers.  With industry and technology solutions evolving at an increasing pace, choosing the most appropriate place and time to invest is paramount to driving down infrastructure costs.  Budget constraints in this economic climate and the make implementing efficiency efforts all the more daunting.

In 2008, Intel IT initiated a Design Server Refresh strategy where the basic premise was to leverage server performance improvements to respond to increasing compute requirements without growing data center capacity at a corresponding rate.  In 2008, we were able to remove 20,000 single core servers from our production environment, allowing us to realize approximately $45M savings through avoiding data center additions and server operating costs.  However, even with this strategy driving significant near term results, the 2009 operating environment forced us to pause and re-evaluate the merits of continuing execution to the strategy.

This re-evaluation concluded that this was an investment that couldn't be deferred due to the need for incremental growth and the high utilization of our existing data centers.  In addition, based on a average 10:1 consolidation, the refresh of single core servers would generate significant operating savings and clear more headroom than seen historically.  The details of this analysis are included in the White Paper:  Staying Committed to Server Refresh Reduces Cost. 

Questions for the readers: Do others have a refresh strategy or guideline? Are others seeing this type of impact/results and the challenges in implementation?

Trying to start off the new year with a question more than a statement as you can see from the subject.  I ask this because of some of the work I am currently doing.  Through the past several months we have been looking a several "influencing" factors and their possible effect on tomorrow's corporate environment.  Things such as consumerization, MID's, netbooks, bring your own computer and even the Generation Y workforce growing in size.  I think one area of "influence" we haven't looked at is legacy IT.  It is just as much an influence as new technologies and trends.  Many shops spend lots of money to put solutions, good or bad, in place.  Invest in infrastructure that made sense 3-5 years ago.  Set roadmaps that made sense when first proposed and established processes for how IT used to work or should have worked.  But the real question today is what would you do different?  Should we take a more agressive approach at End of Lifing pre-existing technologies and solutions that seem to cost more to support today or in some case are here to solve a problem that doesn't exist or has moved on somewhere else. What about out sourcing, how many jobs today no longer make sense from a corporate stand point?  Providing a service is one thing, but if you are providing the same service as the vendor at a higher cost, that really doesn't make sense.  I guess what I am really looking for is what is the value add?  What would you different and what is the value add you feel it would bring to your IT?

Just some food for thought to start the new year, I don't think there is a right or wrong answer, simply some space for some sipirted discussions

Please share your thoughts!

It is vitally important to give data consumers an indicator of the quality of your information. This helps to build a trust in the completeness and review state related to what they are consuming. What we have implemented is real-time, includes embedded business rules and a pretty little display.

So what did we do?

• Created a Five tiered rating system Data Quality(DQ) State

• Moving through each tier means that data completeness and audited quality checks are performed

• As the software application moves through its life cycle, additional data elements become mandatory, which effects the dynamically calculated rating

• DQ State value exposed for interfaced consumption

• Shown on-screen with graphical representation

What is involved in each DQ State tier level?

• DQ State 0: does not meet minimum required data

• DQ State 1: Name, Business Description, Status, Manufacturer, Owner (Group/Contact)

• DQ State 2: State 1 plus - Host, Software Type, User (count/location), Data Classification, Technology categories

• DQ State 3: State 2 plus - Cost Assessment

• DQ State 4: State 3 plus - Capability categories, Network communication details, Business Continuity details

This tiered approach begins to define higher quality for the data completeness as it moves up the defined levels. Not only having the blanks filled in, but the application of embedded business rules-based analysis to validate content, drives the state calculation. These are updated based on any change to any of the evaluated content.

What do you do in your organization? How do you ensure that the data "freshness" is preserved?

Previous topics include Application inventory, what do you capture?, Application inventory starts with a definition, Application inventory as a cost savings initiative and Application Inventory, the start of data sustainability?.

Up to this point I have covered Application inventory as a cost savings initiative followed by a discussion of Application inventory starts with a definition, and finally Application inventory, what do you capture?

Following the natural progression of:

• Why inventory

• Boundaries of what to capture

• What to capture

• How to capture

The "How to capture" is not a simple task completed in a week or two. For a company our size this task is still ongoing after fourteen months. And our progress shows us that we will need at least till the end of year to approach some semblance of sustainability. By sustainability I mean that the information, process and people will be in place to keep the data in a fresh state so that true data-based decisions can be made at near real-time.

Every day the clarity of our inventory gets sharper and sharper as we identify and pull in the data owners. The quality of the information becomes more focused as more of the profile is filled out. There are internal systems that are starting to rely on the data we have captured. That data is being transformed into true business information which has value and can be used to make the right decisions at the right time. At times, it still feels like an uphill battle. Each day we stand side-by-side with those who see the value and push on the back of our partners as we slowly progress up the hill.

Now knowing the definition and what data we want to capture we could have progressed in a multitude of ways:

• Distributed work-load, individual owners

• Focused work-load, our team owning (interviewing)

• Centralized gathering (combination of above, driving people to a single location)

We chose to adopt the creation of a simple to use, centrally located (Intranet Application), that stored the data we needed. As mentioned in the past, we did our analysis by looking at applications on our enterprise that already contained the types of data we were interested in. What we discovered was that none of them had the flexibility to store the additional information nor the development resources to alter their systems. This pushed us to obtain permission to build a new application.

At this point you may be saying, "You built an application to reduce the number of applications?" Sometimes it is necessary to do the wrong thing in order to do the right thing. It would have been too easy to drop a spreadsheet out there and start gathering information. Short-term this would have cost the least and potentially would have allowed us to get part of the way there. The issue is the long-term sustainability and trust that comes from a solution like that. We would have security concerns, updating collision as well as the reduced ability to share the data easily with other applications.

Yes, we built a new application, using two people, in four weeks. Since implementation started we have supported weekly releases while expanding the data being captured, the usability for customers (and consumers) as well as enabling the removal of the majority of those other systems with parallel capabilities. We have great internal hosting solutions and have been operating non-stop since December 2006.

Our goal is still to do the right thing and properly manage our inventory through reduction. We were instrumental in providing the information and process needed to remove over 500 applications (and associated hardware) from our environment since we started our process.

In my next entry I will talk about some future enhancements to get us through the next year and the further reduction in application inventory we are charged with. Perhaps its time to start looking at how our original analysis for "Low Hanging Fruit" was successful and now we find ourselves making hard decisions in order to continue refining our inventory.

Have you had similar issues at your company? Do you currently have this challenge before you? I'm curious to hear some of those challenges and potential solutions.

Every software project I have worked on always started with some form of conflict and complicated interactions.  This usually resolved itself through the use of a definition regarding roles and responsibilities.  That definition kept people on the same page and helped everyone to understand who was doing what.

Now depending on when you happened to look at my job title over the last 13 years, you may have seen one of the following:

• Software Engineer

• Application Developer

• Enterprise Application Developer

• Software Developer

This means only that I moved from one department to another, however, the physical tasks I employed were the same.  My output may have had a different installer/wrapper/output, however, it was the same.  I designed, developed, tested and deployed an application into our environment.

When it was time to define the characteristic (metadata) of an application, we needed to start with definitions. Not only what an "Application" is but what "Software" is and how (if) it differs from each other and from an "Operating System".

This is vitally important because no matter who you talk to, they will have a difference of opinion in this area.  Let me give you an example that we are currently dealing with.  We are implementing a CMDB (Configuration Management Database) for our Service and Support organization.  As our application data is pumped into that solution we had to decide whether it is an application or software.  The CMDB definitions basically stated that software was the core items used to build a hosting platform whereas an application is the code hosted on that platform.  A very specific definition for their very specific implementation.

Our definition was much more simple.

If it's coded, if you develop it, it is a software application simply referred to as an "Application".  This can be developed internally or purchased.  An application is not an operating system.

That means that everything running on our environment, that is loaded on top of an operating system, is an application and needs to be inventories.  That also means if it is a web-based solution, with software code, hosted within a web-hosting solution, however, it is still an application.

We did draw a very discreet line in that we did not want to inventory certain things.  Those are items that are "configured" inside of other applications.  Item such as:

• Web sites without dynamic content, hosted within a dynamic web solution such as Microsoft Sharepoint or created with Microsoft Frontpage or another WYSIWYG client.

• Templates configured for an application.

• Fileshare

• Hosting Platforms (configuration of hardware and application software)

To put forth some simple rules, that people can evaluate their "Application" before attempting to add it for evaluation, we came up wtih some simple rules.  It has to meet all of these with a yes response.

• Installed on Intel (or contracted) hardware?

• Initially used by more than one person (or application) at Intel?

• Does this have (or has it ever had) a development/support team?

• Does this have (or has it ever had) a development/release process?

This minimizes the possibility that we inventory applications that are sitting in a box, not installed on the environment.  It also means that items we paid for, installed, licensed and such, are included.  Whether on a server or on a client, we need to know about them so that we can work towards the simplification of our inventory.

Next I will cover how we have gone about gathering this data.  Some approaches work well while others don't.  Additionally, before you start gathering data you must have a solid review, maintenance and data quality processes in place or the data will be of no use for future analysis.

Have you undergone a similiar process?  Are you struggling with doing this inside your company?  Have questions?  Let us know.