Data Center Pulse Blogs


Data Center Infrastructure Management - Where's the Beef?

Vendors and pundits alike have asked the question, "what's the problem with Data Center Infrastructure Management (DCIM). Why is there no real traction in a market that should be measured in the billions?" Is the lack of traction due to poor products or are the products too pricey and complex? The answer to the adoption problems are more difficult that you might expect because it's yes and no to each of the aforementioned potential reasons and more.

Schizophrenia

There's a general lack of acceptance or understanding of what a DCIM tool is supposed to be. Is it asset management, capacity planning, resource management, environmental controls, automation, or all of the above and more? When the customer hears too many voices, they tend to ignore all of them, at least I do.  To combat this issue, DCIM vendors will have to get better at highlighting and demonstrating value in a clear and simple way. I know this seems obvious, but I would argue that the majority of Data Center operators aren't listening yet, likely because they haven't "heard" the right message.  A well-executed DCIM project takes time and effort, time and effort that are not likely to be prioritized or assigned in clear goals or data center KPIs. Beyond creating a clearer and more pointed message, the DCIM vendors are going to have to build relationships with buyers as a way to help the buyer develop goals that benefit from the implementation of DCIM.  The traditional drop-in, sell something and record a win for the quarter won't cut it in the vast majority of enterprises.

What's the biggest issue?

I eluded to it in the previous paragraph, but to me what is and what has been the biggest issue with the adoption of DCIM is the lack of a single owner for the company data center(s). I know it sounds odd to suggest that not everyone has a data center manager or at least a person who plays that role on TV, but it's true. Most companies have at least created the role of "Data Center Manager" (DCM), but the question is; what is this role actually responsible for and who are they responsible to? I've been a DCM, and I've had the role report to me many times. In most cases the DCM is responsible for basic data center issues like capacity, security, and IT operations functions done within the confines of the DC. What's missing is the link between IT and Facilities, and a demand for a holistic report on the performance of the data center.

What's the problem with not having a holistic view and owner for the DC?

How do you sell a new roof to apartment dwellers? What if there wasn't a property owner/manager available? These issues and many more are what create adoption problems for what would otherwise be terrific data center products and services. If there isn't a single person responsible for all things data center (HVAC/Land/Emissions/PUE/Power costs/Network access/Generator maintenance/Operations Staff/Security/Capacity planning/Asset management, etc., etc.) and whom is expected to report on performance to the C-Suite how can you sell a product whose best selling point is "holistic data center improvement".  Also, since there are no companies sending out a person to be trained on owning and operating the company's $100 million data center(s), there are few if any vendors offering the comprehensive training required. Don't get me wrong, there are lots of great classes out there for training on all the different subsystems that support a data center. Unfortunately, none of the individual subsystem training options give you a "data center manager".  

So what to do with products like DCIM?

The truth is I think many vendors will struggle unless they can create a message that resonates with a specific IT or Facilities function, they can then focus on getting their foot in the door. Once inside, they can create value, which will allow them to make headway across functions.  For the IT or Facilities buyer, if you're interested in getting DCIM, pick an area where you can get an easy win (don't boil the ocean), then work on gaining broader cross functional acceptance.  DCIM isn't the only product or service affected by this "lack of a perfect buyer" syndrome, but it is one of the better examples.

Treating the Data Center as a System is another approach

I've been an advocate for treating the data center as a system for many years now. In fact at Data Center Pulse we created the "Data Center Stack" to help customers with a visual reference to work from when communicating issues, opportunities, change, or links across the entire holistic view of the data center.  Many of today's better DCIM products have a depth and breadth of capabilities that can scare the prospective customer.  Because most data center folks have a more narrow set of responsibilities, helping them to see the data center as a system might entice them to consider a comprehensive DCIM solution instead of point fixes.

DCIM is Dead, Long Live DCIM

How the future data center will incorporate building management systems, DCIM, infrastructure platforms, and cloud APIs is hard to foretell, but it's safe to say that more visibility and real-time responsiveness in the data center isn't a temporary demand or trend. As more functions become centralized in the data center and IT gets even more embedded in everyone's lives and places of work, the demand for improved data center performance will only increase. Show the customer where the beef is and they'll come buy it. However, keep in mind that you might need to size your pricing based on the customers appetite.

Some additional DCIM Related blogs on Data Center Pulse:

DCIM it's not about the tool, it's about the Implementation

Before you jump in on the DCIM Hype

Real-time Data Center Inventory Management

 

Data Center Infrastructure Management - Where's the Beef?

Vendors and pundits alike have asked the question, "what's the problem with Data Center Infrastructure Management (DCIM). Why is there no real traction in a market that should be measured in the billions?" Is the lack of traction due to poor products or are the products too pricey and complex? The answer to the adoption problems are more difficult that you might expect because it's yes and no to each of the aforementioned potential reasons and more.

Schizophrenia

There's a general lack of acceptance or understanding of what a DCIM tool is supposed to be. Is it asset management, capacity planning, resource management, environmental controls, automation, or all of the above and more? When the customer hears too many voices, they tend to ignore all of them, at least I do.  To combat this issue, DCIM vendors will have to get better at highlighting and demonstrating value in a clear and simple way. I know this seems obvious, but I would argue that the majority of Data Center operators aren't listening yet, likely because they haven't "heard" the right message.  A well-executed DCIM project takes time and effort, time and effort that are not likely to be prioritized or assigned in clear goals or data center KPIs. Beyond creating a clearer and more pointed message, the DCIM vendors are going to have to build relationships with buyers as a way to help the buyer develop goals that benefit from the implementation of DCIM.  The traditional drop-in, sell something and record a win for the quarter won't cut it in the vast majority of enterprises.

What's the biggest issue?

I eluded to it in the previous paragraph, but to me what is and what has been the biggest issue with the adoption of DCIM is the lack of a single owner for the company data center(s). I know it sounds odd to suggest that not everyone has a data center manager or at least a person who plays that role on TV, but it's true. Most companies have at least created the role of "Data Center Manager" (DCM), but the question is; what is this role actually responsible for and who are they responsible to? I've been a DCM, and I've had the role report to me many times. In most cases the DCM is responsible for basic data center issues like capacity, security, and IT operations functions done within the confines of the DC. What's missing is the link between IT and Facilities, and a demand for a holistic report on the performance of the data center.

What's the problem with not having a holistic view and owner for the DC?

How do you sell a new roof to apartment dwellers? What if there wasn't a property owner/manager available? These issues and many more are what create adoption problems for what would otherwise be terrific data center products and services. If there isn't a single person responsible for all things data center (HVAC/Land/Emissions/PUE/Power costs/Network access/Generator maintenance/Operations Staff/Security/Capacity planning/Asset management, etc., etc.) and whom is expected to report on performance to the C-Suite how can you sell a product whose best selling point is "holistic data center improvement".  Also, since there are no companies sending out a person to be trained on owning and operating the company's $100 million data center(s), there are few if any vendors offering the comprehensive training required. Don't get me wrong, there are lots of great classes out there for training on all the different subsystems that support a data center. Unfortunately, none of the individual subsystem training options give you a "data center manager".  

So what to do with products like DCIM?

The truth is I think many vendors will struggle unless they can create a message that resonates with a specific IT or Facilities function, they can then focus on getting their foot in the door. Once inside, they can create value, which will allow them to make headway across functions.  For the IT or Facilities buyer, if you're interested in getting DCIM, pick an area where you can get an easy win (don't boil the ocean), then work on gaining broader cross functional acceptance.  DCIM isn't the only product or service affected by this "lack of a perfect buyer" syndrome, but it is one of the better examples.

Treating the Data Center as a System is another approach

I've been an advocate for treating the data center as a system for many years now. In fact at Data Center Pulse we created the "Data Center Stack" to help customers with a visual reference to work from when communicating issues, opportunities, change, or links across the entire holistic view of the data center.  Many of today's better DCIM products have a depth and breadth of capabilities that can scare the prospective customer.  Because most data center folks have a more narrow set of responsibilities, helping them to see the data center as a system might entice them to consider a comprehensive DCIM solution instead of point fixes.

DCIM in Dead, Long Live DCIM

How the future data center will incorporate building management systems, DCIM, infrastructure platforms, and cloud APIs is hard to foretell, but it's safe to say that more visibility and real-time responsiveness in the data center isn't a temporary demand or trend. As more functions become centralized in the data center and IT gets even more embedded in everyone's lives and places of work, the demand for improved data center performance will only increase. Show the customer where the beef is and they'll come buy it. However, keep in mind that you might need to size your pricing based on the customers appetite.

Some additional DCIM Related blogs on Data Center Pulse:

DCIM it's not about the tool, it's about the Implementation

Before you jump in on the DCIM Hype

Real-time Data Center Inventory Management

 

My move to SDL

It’s the weekend before the holiday season and just like last year I find my self at an US airport making my way home… just in time for Christmas.

Sitting at the airport lobby, listing Christmas songs, I can’t help to reflect on the past year.

A lot has happened and things changed a lot. I have left OCOM (LeaseWeb/EvoSwitch/Dataxenter) after 2 years in September this year. Something that some of my peers in the market didn’t expect, but was long overdue. For too long I couldn’t identify myself with the way the company was run and its strategy. No good or bad here… just a big difference of opinion on vision and execution.

The last 2 months I have been able to talk to lots of different organizations in an effort to see what my next career step should be. I needed some time to recuperate from my little USA adventure with LeaseWeb & EvoSwitch. It was a great project to participate in but all the travel took a big toll on my personal life and me.

I also learned how passion for your work can be killed and what it takes to be sparked again. And how people are motivated by the Why in their jobs.

I had some good conversations with DCP board members Mark and Tim about my frustration in the lack of progress in the datacenter industry. It felt like I have been doing the same datacenter and cloud talks for the last 3 years, and things still didn’t move. I wanted to have the opportunity to really make a difference.

In November this year I joint SDL as the VP Global Cloud Operations. Again something most of my peers didn’t expect.

SDL’s services are based around language translation, customer experience and social media intelligence. Most of them are geared toward a CMO and its department. The company is making an aggressive play in to the PAAS/SAAS market.

Gartner has identified the potential of CMO’s moving in to cloud computing consumption publishing “The Top Four Impacts of Cloud Computing on Integrated Marketing Applications “.This is based on the prediction that in 5 years from now the CMO’s will spend more then most CIO’s.

Running this PAAS/SAAS environment requires a large-scale infrastructure that is able to handle high volumes of traffic and data storage. Being able to deliver these services on a worldwide scale, with the ability to scale-out, don’t only require technical transformation but also process & organizational.

During my conversations with SDL’s leadership (and specifically its CTO) their vision around infrastructure and service delivery lined up perfectly with mine. It encompass everything I worked on the last 5 years and the associated vision I evangelized for many years; DevOps, Kanban, Infrastructure as a Service (and the true meaning of the ‘service’ part), BigData, etc..

The next months and years I hope to execute on the companies cloud vision and build the needed reliable & scalable infrastructure and a world-class team to build & support it.

In the coming months I will share more information on SDL’s journey.

Have a great Christmas!

EE-IAAS – call to join IAAS energy research

The cloud market is hot. The IAAS market sees a lot of growth and new IAAS providers seem to entering the market on a daily basis. Enterprise IT shops are exploring the usage of public cloud solutions and building their own private cloud environments.

IAAS distributions like OpenStack and CloudStack seem to have thriving communities.

Organizations that are successful in deploying IAAS solutions, either for customers or internal use, see rapid growth in demand for these services.

IAAS services still need IT equipment to run on and datacenters to be housed in.  While there has been a strong focus on making the datacenter facility and IT equipment more energy efficient, not much is know about the energy efficiency of software running these IAAS services.

The Amsterdam University of Applied Science (HvA) lanced an energy consumption lab focused on energy efficient software called SefLab 1,5 years ago.

Several EU Datacenter Pulse (DCP) members donated time and equipment to the research during the launch.

During the start of the SefLab students and researchers got familiar with the research facility and its equipment. They did a webbrowser compare on energy usage. (results on the SefLab website)

Now that the lab is operational, its looking for new area’s of research. One of the focus areas is the development of IAAS distributions like CloudStack, OpenStack, etc.. and their energy efficiency; what are the effects of architecture choices?, is their a difference in energy efficiency between the distributions ?, what power-manager & reporting elements are missing from the distributions ?

The HvA and SefLab are looking for:

  • IAAS distribution users willing to participate in the research. This is possible in several ways ranging from active participation in formulating research questions, managing a subproject, and supervising student projects, to participating in workshops and events of the project.
  • IAAS distribution communities willing to participate in the research. Future development of IAAS energy management components can be tested and validated in the SefLab facilities.
  • Vendors willing to support the effort with knowledge transfer and hardware/software donation.
  • Industry groups willing to support the effort in knowledge transfer network.

The research done by SefLab is really end-user driven, so this is a natural fit with DCP’s strategy.Details can be obtained by contacting jan.wiersma@datacenterpulse.org

DCP members will be updated on the projects progress using the LinkedIn DCP member group.

See full call for participation here.

If the Tech Doesn’t Fit, You must Convict

The usual arguments on Twitter about new technology and solutions run the gamut from "it isn't real" to "there's only one real cloud". These "discussions" seem to go on and on and every time a new solution is introduced they are reignited.  Is all tech questionable, are all services terrific, are particular services better from specific vendors?  Most often it's more about fit in a specific organization or company, so how you position yourself is the key.

The rub

Too many vendors make claims that they don't need to make. The claims are wrong or at a minimum a reach, yet the technology underlying the claim is actually good. Why add "It even makes coffee" to an advertisement about a Swiss Army knife? Doesn't the knife already do many useful things very well? If you've got a good product, sell it on its merits.  In the case of modern technology solutions we're often hearing one or more of the following three terms "cloud", "bigdata", and "SDN".  Really, you've added a management tool to vSphere and now you have a "cloud" product?  You provide a data sync solution for Terredata arrays and that means you're in the "bigdata" market? Maybe you've figured out how to apply passwords to a common set of switches with a single command, well then yes, you must have an SDN product.

My biggest beef is with the use of the term cloud to support almost every new product and service release. Even the phone company thinks it's important for the customer to believe their service is running in the cloud. I mean really, who cares? But even more specifically it's the marketing pitches of cloud ish products to internal IT teams that are driving many of us in the Twitterverse to frothiness.  Consider the debate about public vs. private cloud. The debate is mostly dead now, and private cloud exists, but you're not doing private cloud beliebers (like me) any favors when you sell a solution that's really just some simple scripts on virtualization and you call it "cloud"

The deal

The deal is, scripts on virtualization can be a great solution. Just because it isn't cloud doesn't mean it's inherently bad, just that it's not cloud.  While "real" cloud may be the long term destination for virtually all infrastructure, it doesn't mean that more effective and automated use of your servers isn't still a worthy pursuit. 

It's also true that in many cases applying some simple automation and virtualization to infrastructure is all many IT organizations should be trying to do (right now). Moving legacy applications to cloud is fraught with risks and limited value. On the other hand, being able to quickly and uniformly applying common policies and or patches to application environments can be real handy. Lastly, many organizations are as ready to adopt cloudy or agile operations as a Yugo is ready to run the Indy 500.

Of course if your product or service sucks, then in the long run it won't matter what you're telling the customer, but you might as well start from a point of trust.

Next time

Position, position, position, it's like the technology vendor equivalent of the real estate mantra of location, location, location.  Determine how and where your solution actually fits in the varied landscape of IT organizations and industry verticals and then put the positive spin on what it really does. I know this sounds like what every company does. Yet interestingly I speak with company reps every day that don't understand the drivers that can and often do affect IT buying decisions. The hardest part is that many of these decisions aren't based on logic. In the world of sales, IT is probably more complex than most any other product or service category.  

 

 

 

 

Enterprise Legacy Environment Cloud Adoption vs Netflix

Two blogs written recently one by @benkepes and the other by @jeffsussna covered the topic of cloud adoption strategies versus legacy and best case environments. In Ben's blog he talked about how Netflix is an outlier in the cloud space. That their applications and use characteristics don't match enterprise use cases and don't match the complicated verticals of infrastructure and applications in the typical enterprise data center.

Jeff's responded to Ben suggesting that he sees the demand for agility in IT increasing the drive of IT organizations to focus on delivering new applications, even to the extent of replacing Tier I "systems-of-record" type applications. The idea of just moving legacy applications via "forklift" isn't really viable and as such companies are looking for ways to replace instead of simply upgrade or move.

I agree with both Ben and Jeff, but differ a little in expectations for what's likely to happen within the average enterprise IT transition to cloud. I do believe Netflix is an outlier, but like the original NASA programs, Netflix, and OpenCompute, etc. are leading indicators/inventors of what's likely to happen in the more traditional enterprise space. So my response to both Ben and Jeff isn't to suggest either is wrong, but rather that both are missing the how and timing of the transition.

There is NO one way for any company or IT solution to proceed

There isn't a single path that companies will follow. The industry in general will often try to pigeon hole the entire enterprise space into a single strategy or a common technology platform. However, if the history of IT adoption has taught us anything, it's that there are few times when everyone uses the same strategy to get to the next level.

If it were me

As a former IT guy (person), I tended to be a little bit of a leading edge type. That being said, I still used a process of value versus risk to make any decisions on moving forward with a major change to applications or infrastructure.  In the case of the move to cloud, I wouldn't use any other approach. As I see value outweighing risk, I would proceed with making an investment in change.

The drivers & process for making change

There are dozens of drivers that need to be weighed before making a major investment in core applications or large infrastructure projects and some of the more common are;

-          Immediate return on investment to the business (value)

o   Not "does it make IT better"

o   Measurement of value is difficult at best, but having the business define the value is critical

o   Will the IT organization be in a position to help the business leverage and grow new application use

-          Having an accurate and realistic measurement of risk (often missing from IT projects)

-          You should measure risk and value against a natural upgrade cycle (In other words, if you would have done a major upgrade within the next year, how does waiting impact your value/risk?)

-          Staffing models versus partners. Having the right team members, and or external partners are foundational questions for how/when to proceed

I could go on with process and driver thoughts, but I'm sure you're getting the gist of it.

What I believe we're likely to see over the next 1-10 years

Enterprises will approach the change in myriad ways as I've already said. However, I think one common approach will likely mirror the following:

-          New applications - Put them in the cloud or explain why they can't be (I'm not making a distinction between public and private cloud, but I will say that there are reasons for using one over the other or both)

-          Old applications that don't have an upgrade value and or aren't likely to be maintained into the future will be left as is, or where easily done moved to the cloud for some efficiency benefits

-          Core applications will be grandfathered over time as key opportunities of value, vs. timing, vs. application replacement options are better understood

-          IT will segment application sets based on infrastructure requirements and for the next 1-5 years we're likely to see a cloud tier approach that has a combination of cloud performance characteristics, scale, pricing, distribution, and reliability (all drivers that can be measured against each application)

-          5-10 years out were more likely to see all but the most hardened criminals applications converted to cloud applications and we're also likely to see the tiering of cloud infrastructure consolidated to 1-2 different performance models

Of course, I could be completely wrong

Predicting the future is both easy (you rarely ever get challenged over what you said 2 years ago) and hard (because most of us don't get it right).  So take this blog for what it is; one person's opinion on how enterprise cloud adoption is likely to unfold over the next 10 years.  If you were to challenge me, I suggest you call into question things like advances in application design, improved conversion tools, better intercloud operability, etc., etc. You also might consider helping determine how a business can easily put a value on moving to the cloud. Right now we all inherently believe in the value, but no one has really drawn a proof of concept picture of how a totally cloud enable traditional enterprise will benefit. In the meantime, keep up the good fight and stay focused on delivering value, whether it means moving to cloud or not.

 

Jeff's blog; http://blog.ingineering.it/post/62910634258/are-we-sure-netflix-is-just-an-edge-case

Ben's blog: http://www.forbes.com/sites/benkepes/2013/10/01/cloud-computing-legacy-vendors-and-the-only-reality-that-matters/

 

 

Forbes Article only tells the old story of the CIO role

In a September 27th article in Forbes written by Raj Sabhlok, the President of Zoho Corp., Mr. Sabhlok discusses the disruption of the CIO role being caused by modern IT solutions (I.e., SaaS, Cloud, consumer IT etc.). The point of the article is correct: the CIO role does need to change. However, I found the changes suggested by Mr. Sabhlok to be both retro and extremely incomplete.

The argument for change in the CIO role

Mr. Sabhlok says (and I paraphrase a little), "Most CIOs today operate in a largely tactical capacity for a relatively naïve user base. That leaves them to oversee fundamental responsibilities such as break fix, password management, software and hardware upgrades and email." So far, no real argument from me, other than to say I think the above statement over simplifies the role of IT. Where I start to differ more directly is the next section of the article, "Overcoming Tactical Irrelevance."

In this section, the author goes on to say that the workforce is growing more sophisticated, and the responsibilities of the CIO will as well. Unfortunately, while I wouldn't personally have written this intro, the author really missed the point in "new areas to brush up on" for the CIO. Mr. Sabhlok suggests that CIOs focus on the following four areas:

"Enterprise Security - To protect the enterprise from security attacks and breaches. CIOs need to be well versed in IT security and compliance."

Really, this is new? Most of the CIOs I know are pretty well-versed with security already. What I believe they aren't prepared for in many cases is the new way security risks will be introduced by consumer IT and having dozens of SaaS applications all independently sourced and managed. This may be a semantics issue, but I think the clarity is important here.

"Project Management - Delivering large and complex technology projects will demand CIO expertise in IT project management."

Dang, all this time IT has been screwed up because CIOs don't have project managers and can't run large projects. How did knowing how to run projects become more important in a time when we're also telling CIOs to stop building so much of their stuff and let others do it. I'm not saying the skill won't still be needed, but come on, we might as well be saying the CIO needs to know how to lead a team.

"Financials - CIOs must have corporate financial skills to understand budgeting and expense management."

Again, how is this a newly important skill? I don't see this changing in any real way except to say that IT might be forced to figure out how to plan for some work being OpEx that used to be CapEx as the average CFO hates inconsistency.

Last but now least...

"Legal - Legal skills will ensure CIOs understand regulations, data storage and retention policies, privacy policies, and "other" contractual issues impacting their companies."

Well, I certainly can't argue that. In fact, I'm pretty sure I helped write that into a CIO job description about 12 years ago and it was pretty relevant 10 years before that. How again is this a new requirement? My opinion is that the CIO will need to gain a better understanding of how using public cloud and working in new countries with multiplied user IT end points might impact data sovereignty and privacy issues. They will also need to gain a better appreciation for what the risks are or aren't if he or she has an issue with a public cloud provider.

My thoughts on the whole thing

I don't believe the author meant to sound like he was stating the obvious, but I do believe that some of the really important needs of the "New CIO" were lost in translation, and others were just plain missed.
Each of the four criteria for the CIO listed above will continue to be relevant in IT for some time to come. However, where I think the author really missed out is where most people seem to fail, and that's in how to build an organization that is staffed and trained appropriately. I won't rehash everything that myself and many others have already written about the changing IT organization, but suffice it to say, it will likely include big changes. Here are a few of the changes/needs I think are likely to be most critical.

IT to Business Functional integration

This has been an opportunity for IT for years, but for a number of reasons it either has not been pursued or fails due to lack of top down support for staff roles and reporting structure. However, the integration of some IT team members within the functional business units is even more critical than ever for a number of reasons; SaaS, cloud, and putting an IT eye on potential business process and innovation opportunities.

Data and Application management in an even more silo'd world

The potential risks of SaaS if not managed well are many, but one of the more obvious is the potential for creating islands of data. The same is true for independent use of cloud resources outside the oversight of IT and or IT tools. Without strong business partnerships and effective IT management tools, the potential risks of opportunities missed and money lost are real.

Training and leadership for a newly aligned IT team

The organizational change required might be the biggest omission in the author's article. Besides the "departmental integration" mentioned above, there will need to be programs that help staff let go of "technology allegiance" in order to focus more on "need/solution fulfillment." There must be new roles defined for negotiations of support and services relative to cloud, SaaS, and consumer-oriented IT solutions. IT will also need to develop a plan for how to put governance on the business use of IT, without treating it like "control."

This is only the beginning

What I've covered here is only a small slice of the kinds of changes IT will need to make, but I felt it necessary to point out that the changes did not fall under the category of "do more of the same old stuff." The debate over the future of IT is still raging, and that's a good thing. If it weren't raging, it would be because the the business was filling out the CIOs walking papers. There's still time as I've suggested in previous blogs, but there's no time like the present to get started on making your IT group as agile and adaptive as the business wants to be.

Professionally copy edited by Kestine Thiele (@imkestinamarie) 

The need for datacenter education in emerging countries.

I recently had the privilege to travel to some of the emerging datacenter countries like Eastern Europe, Russia, Middle East, Africa and some of the Asian countries.

While I was impressed with the deployment of mobile bandwidth & devices the conversations with datacenter owners and operators scared me. With more and more people getting internet access in these countries, the need for local datacenters also rises. Taking the time to really talk and listen to the stories of some of the local datacenter owners, it reminded me of the way datacenters were build and operated 10 years ago in most western countries.

Zooming in to the way these local operators and owners gather their knowledge, two things stuck me:

  • Most of them aren’t connected to industry groups or communities like Datacenter Pulse, 7x24 Exchange, Uptime Institute, etc… Sometimes this is a cultural or language barrier but most of the time I found this to be an awareness issue.
  • There aren’t as many industry conferences in those locations. It’s hard for conference organizers to get something going from a sponsor & revenue perspective. So where do local operators go to learn?

I think the larger datacenter vendors need to step up and take responsibility. I think western datacenter owners and operators have a moral responsibility to go out and educate.

We need to send our Dr-Bob’s out and educate them on the benefits of retrofits of old facilities. We need to send the industry leaders (either vendor or DC-owners) out and educate the emerging countries on the technical opportunities they have for the many greenfield projects begin run in those countries.

This way they know what technology is available before some of the old-fashioned datacenter consultants step in and copy-past our 10-year-old datacenter designs. This way we protect them from mistakes we already made and they can leapfrog in to a brighter datacenter future.

I know this sounds idealistic be we owe that to these emerging economies, especially from a resource (like energy) efficiency perspective.

So if you have the chance to travel to emerging datacenter countries, take it. Share, lecture, educate, and try to protect the local operators and owners from making the same mistakes we made 10 years ago. They deserve that chance.

Believe me… it will make the world a better place.

Keeping IT Relevant isn't about the Title of the CIO

Chief Information Officer, Chief Innovation Officer, Chief whatever, no chief at all, it doesn't matter. What really matters is whether the person responsible for IT can bring IT opportunity to bear on the business effectively and quickly. I know, simple concept and it's been said a thousand different times, 10 thousand different ways, but I'm going to try one more time. "The appropriate expectations from the business combined with the appropriate philosophy in the IT organization is more important that the title of the man or woman in charge."

Innovation is the closest descriptor

If we have to pick a name, then I suggest we pick Chief Innovation Officer.  The goal of the IT function should be to use all the creative and innovative technologies and solutions available to innovate "new" business capabilities. Sadly, most IT organizations are more focused on delivering what their customers ask for, even though the customer often doesn't know what to ask. Then they spend the other 75-85% of their time "keeping the lights on" or finding ways to "save money on the cost of IT".

Unfortunately, most of us in IT think we're innovating when we take a business requested application or solution and build it a little faster, a little cheaper or with a few more or less buttons. Sadly, this is the "follower" model of product design and delivery. Make no mistake IT is in the product /service design/select and delivery business.  You can't deliver innovation in technology if you're waiting for your customers to do the innovating.

Apple is the best model

While there are other companies that we could reference besides Apple as a model of designing what the customer "is going to want", Apple is easily recognized and better understood than any other.  It's not to say that customer feedback can't be useful, but if you're designing something net new, you can't wait for the customer to know what they need first.  Let's consider reversing the equation, instead of the IT department being responsible for innovation, we're now asking the rest of the company to play that role.  By asking the business to take ownership for IT innovation you're effectively saying that the 50 people in Marketing (or any business function) are somehow better equipped and more IT aware than the same 50 people of another company. How and where is the competitive edge acquired? The answer is that "it's not".  It's hard enough in the average IT department to get staff to focus on R&D/Innovation for even 10% of their day and it's "their job", yet you expect someone with a full time gig in marketing to do it, really?

Embedded IT

A hybrid approach to IT staff development and distribution is required and a major part of the approach is to have some IT staff embedded within each department. I know this isn't new, but it also isn't done very often and usually not very well.  It still surprises me when I talk with an IT person who says with surprise in their voice "yea, great idea to have someone follow a manufacturing employee around for a few weeks".   It seems that few companies are embedding staff within the business, even though it's the best and fastest way to identify and create new business opportunity with IT.

The hard part for most CIOs is often the matrixed organization issues of who really owns the embedded staff and where do their priorities lay. However, the potential benefits of having embedded IT staff far outweigh any upfront hassle in justifying their roles and determining leadership and management strategies.  

How do embedded staff create the Apple model

Embedded staff don't create the Apple model magically, but they're a big step in the right direction. The only way you can successfully create the Apple model is to lead by example.  As the CIO you must convey to your team the critical importance of their responsibility to rise above the daily noise, and find the diamonds of opportunity that would otherwise have been missed.  If your embedded staff is bogged down with internal meetings, operational overhead or projects that don't have a direct impact on the group they support, then you aren't showing leadership.  By having the IT staff watching, living, listening, and participating in a business function you're much more likely to get ideas that innovate how things "can be done".  Not every IT staffer is going to be a good fit for this type of role, so you might have to do some rotations before you find the right person.

Ramifications for the entire IT organization

There are ramifications for the entire IT organization when pursuing a staffing model that includes technical and business savvy folks being embedded within each of the functions. There is the risk of further stratification of IT between the "innovators" and the "operations teams".  There is the risk of having a distributed team performing poorly or not communicating without greater leadership focus. The fact is, there isn't an easy way to slice this artichoke and someone's ego or job function is likely to get poked. However, if you have the courage to make the necessary changes and make the tough calls on staffing models based on people and opportunity not silos or turf, you can make it work.

The future view

In the long term (3-7) years, the IT organization is going to be forced to change considerably. Even if it's an "effective" function, it's likely that more services will be outsourced or hybridized. I suggest getting ahead of the curve and positioning your team and the IT function to take a leadership position in order to leverage rapidly iterating IT solutions and services. Put the team in a position to quickly and effectively apply solutions to problems in days or weeks from the point of discovery, instead of years. 

A Potential Org Breakdown

There might even be reason to consider creating an entirely new distribution of what was formerly the IT organization. Instead of having a single group that includes everyone from PC Support up through Coders, Architects and Business Analysts you might end up with something like the following:

  • IT Operations within the COO function of the business
  • Core development for application modification/design and data integration efforts (Technology Development)
  • Embedded Innovation and Liaison staff or Business to IT solution translation & innovation (these team members could also be rotated members of the other two functions depending on skills and experience)

Tricky aspects of this org include risk of a breakdown in communication (worse than normal), differing priorities, etc., etc.

The above is just a thought on "a potential" org design. Keep in mind that organizations get reshuffled every 2-3 years in most companies and rarely do things really change. What's actually important is how the organization is cared for and fed by its leaders.  

Act on what you know is coming

The simple message here is that the way we deliver IT solutions to our customers is rapidly changing and speed and choice will continue to gain importance.  When you're keeping an application for seven years, a six month delay at one end of the project or the other seems like a small thing. However, if you're keeping an application or solution for only two years, six months takes on a whole new meaning. If you consider delaying projects even further by waiting for your customers to hear about what another company already did, you're really going to miss the boat. 

 

The pain and risks of ignored IT infrastructure

Cancer, aches & pains, ticking time bombs, pick your term du jour, they all apply when IT solutions are ignored and left to grow roots. There are many reasons why IT solutions are left behind to grow roots, but in this blog I'm focusing on the process of integration after a corporate acquisition as the antagonist. 

Human behavior, resource allocation and or risk assumptions

Corporate acquisitions are a time of excitement, fear, opportunity, and most importantly pain and all of this is tied to "change", which is a huge problem for virtually everyone. There are many great books about how to better manage change in your life and your career, but this blog isn't so much about change as it's about leveraging the opportunity associated with change more effectively.

The human equation is interesting to me as it is rarely quantified in project planning, and doesn't show up on the ROI assumptions. Yet, when the human equation is ignored you will likely fail in whatever endeavor you've embarked on.  The activity of corporate acquisitions causes no small amount of fear and bad behavior amongst employees in both companies. On the one hand those being acquired are concerned about reporting to new bosses, changing job responsibilities, lost importance, new company culture, and even worse the prospect of maybe losing their job. On the other hand the acquiring company employees will suffer from some of those same concerns, but most often the problems are related to a lack of empathy and or an attitude of superiority towards those being acquired.

The weakest link is often the leadership team's failure to take the human equation into account. When leadership doesn't adequately plan for how to deal with the resulting human problems the seeds of dissent are sown. The seeds of dissent are often manifested in passive resistance and in some cases outright rebellion as it relates to building the new company vision. This resistance and rebellion are a big part of whether or not you have a successful integration. By successful I mean one year after the acquisition your infrastructure and applications look like they are "one" company and your employees act the same.  To avoid these issues the leadership team must apply several fundamental rules of engagement:

A Few Critical Rules of Engagement:

  • Tell the truth, all the truth and nothing but the truth to both companies employees (This one is most often ignored. At least that's been my experience
  • Have well defined guidelines for what technologies you'll keep, what you'll integrate and what you'll retire (Too often an afterthought)
  • Establish clear (and truthful) employee integration, training and opportunity communication plans
  • Resource effectively so that you can manage the human equation and complete the integration against a well-defined timeline (this means department level staff whose fulltime duties are the integration)

How the above is related to islands of IT left to fester

I like to use an old quote from my dad "would you rather pull the Band-Aid off one hair at a time, or rip it off and get the pain over with?" The simple message here is why prolong the agony if in the end the pain is actually worse? All too often as part of acquisition integrations we avoid decisions on what infrastructure or applications to keep, and what to retire until years after the business side of the activity has been completed.  This delay in "ripping the Band-Aid off" can and often is the cause of major cost, staffing, and complexity risks to your IT.  Many of us now acknowledge that most IT organizations spend ~75% of their time "keeping the lights on". Often a big part of that 75% figure is directly associated with poor decisions related to ripping the Band-Aid off.

The main point of this message regarding ripping the bandage off is simply that there is already significant change (pain) occurring as a direct result of on-going acquisition activities.  Would you rather delay the necessary activities of real IT integration and rationalization and cause even greater pain at a later date or get the dirty deed done so you can move on? You can pretty much guarantee that delaying the activity will cause greater pain. The longer you wait, the deeper embedded the infrastructure or application is likely to become and by embedded I mean IT staff and customers are more invested in it.

Been on both sides

I've been on both sides of the acquisition effort and have seen many things done wrong, but most often the missed opportunities are related to the bullets above. On several occasions I've had to be the bad guy and fix the infrastructure of my employer when they've ignored the Band-Aid rule in the past. I've also had to struggle with integrating an acquisition where the infrastructure and application environments make it look like they are five companies instead of one. Trust me when I say ripping the Band-Aid off quickly is almost always the best way to go.

Don't be an ostrich

Don't stick your head in the sand and hope the problem will go away, because it won't. Ignored IT environments have a bad habit of growing into something that becomes "critical" or overly "integrated" to other systems. The longer the environment is left to fester, the more critical it becomes (read: infected). Once you have people and process invested in trying to protect turf and therefore the future of an environment, the removal difficulty goes way up.

Think two or three times and act once

The next time you're involved in a major change event at work, whether it's an acquisition or other fundamental shift think long and hard about what you want to own after the change has occurred and acknowledge the human aspects of your decision.  Then go about making the changes quickly, and honestly, you'll be better and healthier for it in the long run.