Bob Deutsche joined Intel in 2004 and has more than 25 years of business and IT experience in positions that ranged from data center operations to software development to CIO. He can be found online at Bob Deutsche on the Intel Server Room.
BOB DEUTSCHEIntel
In my last post, I introduced a table of components to consider when you’re developing a scalable cloud solutions framework. I suggested that due to organizational dynamics and the fundamental distrust of IT in many companies, some might bypass these components for the sake of expediency and cost. The key takeaway, and the subject of today’s column, is that to build a workable solution framework, you need to understand considerations that are larger than IT and the data center. In other words, considerations that go to the heart of your business (without any of the baggage that technology may introduce into the discussion).
Lessons Learned from Auto Racing
Consider a simple analogy. The historic and grueling 24-hour automobile race at Le Mans (24-Heures du Mans) runs every June in France. It tests hardware reliability, driver endurance, and team strategy. Arguably, one considers a win at Le Mans as the career pinnacle for both an auto manufacturer and a team of drivers. In the early 1960s, Ford Motor Company decided to go racing with the goal of winning at Le Mans, which meant displacing Ferrari, the powerhouse of that era in GT racing.
As you might expect given its resources, Ford assembled a formidable team (or, in data center terms, a solutions framework with legs and arms) composed of engineers, constructors, management and drivers, with the single objective of building a racing platform that would win Le Mans in 1964. The result was the legendary Ford GT40. Three GT40s were entered in the 1964 Le Mans race. Although they performed well for their first time in competition, none finished the race. Ferrari’s cars finished in five of the top six places. Hmmm… If the solution framework looked so good on paper, what happened?
Given the embarrassing end to what (at least according to the solution framework) should have been a slam dunk victory for Ford, the company took a slightly different approach moving forward. This time, while maintaining the fundamentals of the initial framework it used to build the GT40s, Ford reached out to a group of California hot-rodders. These hot-rodders not only appreciated Ford’s original framework, but also understood elements outside the corporate world that Ford needed to align in order to win at Le Mans. In 1966, Ford’s GT40s placed first, second, and third and then went on to dominate the race for the next four years.
Cloud Solutions & Ford's Desire for A Win
You may be wondering how this relates to a cloud solutions-based framework. It’s a fair question. Remember that in my last post I introduced a hypothetical vice president of sales who had just contracted to implement a new cloud-based, outsourced customer relationship management (CRM) system. (Think of this person as Henry Ford II, CEO of Ford from 1960 to 1979.)
At the end of the discussion, our sales vice president had little concern about a solutions framework -- it was about deadlines, budgets, resourcing and selling more widgets with less overhead cost. Similarly, all Henry Ford II wanted out of his GT40 program was a victory at Le Mans. Are you starting to see the parallels?
As Ford II found out in 1964, just pulling together a team (solutions framework) with the right skills and components doesn’t mean your plan is fool-proof. Factors outside the framework can still ruin your plans. So, if a core cloud solutions framework is more than hardware or software, how do you convince your sales vice president that he might need to care about something beyond pushing more widgets out the door?
In Henry Ford II’s case, it was simple. He still hadn’t won Le Mans, so obviously the realities of the broader framework impacted his success in the 1964 race. He needed to find people who understood these realities and were experts at linking core solutions into a viable delivery system.
For our sales vice president, the discussion might also be this easy, since he’s likely more plugged into the broader corporate ecosystem than you are. This makes him more aware of the “oopsies” that could impede the success of his new CRM system. Your role at this point is to simply remind him about these considerations, and help work through the potential impacts on his cloud-based customer relationship management system. By helping him, you’re actually helping yourself—and the enterprise.
Here’s what a list of those considerations might include:
CLOUD SOLUTIONS-BASED FRAMEWORK CONSIDERATIONS
|
Geopolitical requirements: Where is your data stored? How do you access it? This varies by industry type, data type, and the legal requirements of your geography. |
|
Security/Privacy: What are your company's security policies, if any? What are your company policies surrounding matters of privacy? Are they linked somehow to security concerns? If so, how? |
|
Industry Direction: Is your industry vertical trending toward shared data or islands of information? Is it well defined or undergoing significant changes that might impact how information is used and shared? What are the time frames projected for these changes? |
|
Corporate Strategy: Is direction from the top, or is the cloud initiative driven by one or more components of your business (which seems to be more the rule than the exception)? |
|
Organizational Cohesiveness: How well do your business units work together? Does the culture measure and reward performance from a functional level at the expense of the corporate level? What has been the history of success in cross-organizational business initiatives? (Cloud requires a level of integration not seen since the days of the mainframe.) How does the corporation see the value of your internal IT organization? (More than likely, you will be tasked to convince everybody to play in the same sandbox.) |
|
Enterprise Ecosystem Awareness and Standardization: Can your company discuss how its enterprise architecture binds business with technology? Is standardization sort of adhered to, at least in spirit, or does your environment proudly support one of everything? |
|
Willingness to Embrace Change: Implementing a cloud ecosystem, at any level, is disruptive. It forces change down to the business and operational levels. How have these types of actions been received historically in your enterprise? Is your company risk-averse or risk-inclined? |
|
Management: Cloud is Disruptive and Requires your Organization to Consider -
|
As was the case with Ford in 1964, nobody on the initial team wanted to reach beyond their comfort zones to suggest that it would take a slightly different perspective to win Le Mans. I suspect the same might be true of an IT or data center type who needs to become conversant in cloud framework considerations that don’t necessarily relate directly to technology. In my opinion (and this is a common theme you’ve seen in all of my columns), right now, you simply have no choice.
In our next discussion, I’ll start to identify something I call fundamental truths of the cloud. As always, I encourage your feedback, specifically on:
1.How cloud found its way into your organization
2.If the journey so far has been systematic or more like putting out a fire
3.What potential data center organizational changes you see coming
If you are shy responding publicly, you can reach me via LinkedIn.
Jusqu’a la prochaine fois. (Until next time.)
Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.
