The Eight Fundamental Truths of Enterprise Cloud Strategy › content › dam › www › public › us › en › ... · Cloud Computing The Eight Fundamental Truths of Enterprise

WHITE PAPERCloud Computing

The Eight Fundamental Truths ofEnterprise Cloud StrategyA pragmatic, business-focused overview of the cloud

EXECUTIVE SUMMARYBeginning in May 2011, I began writing a series of blogs featured in Data CenterKnowledge (DCK), a daily news and analysis website for the data center industry. In par-allel, I blogged for the Server Room in Intel’s Open Port IT Community, introducing thesame topics to a different group of readers.

The purpose of these blogs was to provide a pragmatic business- and enterprise-archi-tect-focused overview of the cloud without any of the associated hype. Toward this goal,I identified a way for companies to build a workable corporate cloud strategy based on aseries of what I call “fundamental truths” of cloud computing. A fundamental truth iswhat I consider to be a principal rule (or series of rules) that can serve as the foundationfor the entire framework. Fundamental truths are inviolable.

Here are the fundamental truths that, I believe, form the cornerstone of any cloud corpo-rate strategy: 1. Large-scale, transformation to cloud computing, including your critical business sys-

tems, is a journey that will take you from eight to 10 years.

2. Cloud is a top-down architectural framework that binds strategy with solutionsdevelopment.

3. Your cloud ecosystem is only as robust and adaptable as the sum of its parts.

4. A services-oriented enterprise taxonomy is not optional.

5. Cloud is a verb, not a noun.

6. Technology-driven business practices often circumvent government regulations, butlegal/government policy standards will dictate cloud’s success.

7. Bandwidth and data transmission may not always be as inexpensive and unencum-bered as they are today (geo-sensitive considerations).

8. Altruistic motives do not generally keep the lights on.

Over the course of about seven months, I expanded on these truths through my blogs.This white paper is a collection of these blogs.

Bob DeutschePrincipal Enterprise Architect

Intel [email protected]

A fundamental truth is a

principal rule (or series of

rules) that can serve as the

foundation for the entire

framework. Fundamental

truths are inviolable.

LET’S GET REAL ABOUT THE CLOUDIf your disposition is like mine, you’re tryingto avoid stomach cramps as you read all thelatest articles, columns, and blogs extollingthe virtues and inevitability of cloud comput-ing as the technology to save the humanspecies from self-inflicted destruction. Aftermore than 25 years of experience in thenetherworld between technology and busi-ness, let’s say I’m more than a bit skepticalabout many of the claims people are makingabout the cloud.

While I‘d like to tell you my skepticism isbased on incredibly high intelligence, simplyput, the bulbs in my chandelier don’t burnquite that brightly. Instead, I tend to viewthings from a common sense perspectivethat evolved and was honed at a boot level(IT and business). Through my many profes-sional lives, I’ve evolved into a principalenterprise architect (EA). If you’re not famil-iar with this term, think of EAs as the folkswho are paid—and supposedly have theskills—to be able to string technology, busi-ness, data, and applications togetherbetween data centers and end users (peopleand devices). If you consider the supportingecosystem (some of whom might takeoffense to the word “supporting”) requiredto make this all work, maybe you’ll begin tounderstand why I have some concernsregarding the cloud.

Here are a couple of conclusions I’ve reachedabout the cloud continuum:

1. By virtue of its reach and associatedcomplexity, a large percentage of thecloud’s purported advantages are self-defeating in a typical enterprise (whenviewed beyond a single business unit)and will likely never be realized.

2. A centralized IT organization’s ability tosuccessfully influence the tactical direc-tion of cloud enterprise efforts by busi-ness users is significantly limited andwill likely hasten movement towards

decentralization (in-house or out-sourced) of these resources to the busi-ness units.

A recent Forrester research paper for vendorstrategy professionals by Frank E. Gillett(“Navigating the Shifts in ComputingInfrastructure Markets,” March 24, 2011) con-cludes that end users (called informal buyersby Gillett) are driving cloud infrastructure as aservice (IaaS) adoption. These informal buyersare not IT operations staff and are seekingquicker and more flexible resources than theirenterprise IT organizations are able or willingto provide. If it persists, this trend has obviousimplications on those centralized IT organiza-tions being bypassed as well as the dynamicsof selling IaaS services.

RETAKING THE HIGH GROUND IN THE CLOUD DISCUSSIONIt’s appropriate for IT and the data center tofind a way of establishing or reinforcing theirvalue in this space without becoming an impedi-ment, perceived or otherwise. Depending onyour relationship with your business partners(time for an honest assessment here, since thisbecomes a key consideration later on), estab-lishing your value may not be easy. But you cando it if you take the enterprise solution per-spective that most IT shops enjoy.

Let’s explore this by looking at how cloud isfinding its way into a typical enterprise. Sayan informal buyer (Forrester’s definition)from your sales organization tells your CIOthey just contracted to implement a newcloud-based customer relationship manage-ment (CRM) system that’s absolutely guaran-teed to be up and running in 35 days. Sincethis new application replaces a legacy sys-tem, the vendor told your vice president ofsales that cost savings are in the bag. You’llbe able to consolidate your data center,which is now hosting the legacy application,and keep headcount low. The vice presidentasks you to supply any links the contractorneeds to the legacy data to get the newpackage to work. Life is good.

The Eight Fundamental Truths of Enterprise Cloud Strategy

2


Trusted Partner or Expensive Necessity?Could something like this really happen?Only you can answer that question, sinceresults may vary. Although the 35-daypromise might be a stretch, the examplemay be more real than any of us would careto admit. It all comes back to your perceivedvalue to the business. (I told you we weregoing to bring this up again.) Are you per-ceived as a trusted collaborator? Or are youseen as an expensive necessity that’s slowand cumbersome and contributes nothing toreducing time to market? Again, be honestwhen you think about this.

Over the course of multiple companies andcareers, I’ve held positions both outside andinside IT and the data center. Having saidthis, and with my business hat on, I oftenfind that IT and data center types have ahard time understanding the perspective oftheir business collaborators—or, even moredisconcertingly, seeing what’s most impor-tant to their companies. This point is crucialfor you to understand just how differentyour view of a cloud solution is from yourbusiness collaborator’s.

Let’s take the perspective of the sales vicepresident. At the end of the day (and admit-tedly, this is over-simplified), the perform-ance and compensation of our hypotheticalvice president of sales is measured usingtwo basic criteria:

1. How many widgets the company pushesout the door per year (likely broken downinto quarterly sales objectives and drivenby the profitability objectives of yourshareholders and enterprise)

2. The cost of sales (very simply, howmuch the company spends to peddlethe widget, with lower costs equatingto higher profitability and happiershareholders)

If a vendor’s cloud solution promises toreduce the cost of sales, and if the source of

that information is deemed credible, that’sabout all that matters to the vice presidentof sales—particularly if he’s not especiallyfond of the enterprise IT organization. Thekey takeaway is that the vice president ofsales views a cloud solution very differentlythan you do. Perspectives are driven by howpeople are rewarded and cloud solutions arefundamentally defined by perspectives.

The IT and data center team is paid to beconcerned about the entire enterpriserather than its individual elements. So, bydesign, you view cloud solutions differentlythan the vice president of sales.

CLOUD LESSONS AND LE MANS RACINGTo build a workable solution framework,you need to understand considerationsthat are larger than IT and the data cen-ter—in other words, considerations that goto the heart of your business (without anyof the baggage that technology may intro-duce into the discussion).

Table 1 shows the components IT and thedata center should consider when develop-ing a scalable cloud solutions framework.The key to introducing these concepts withoutbeing perceived as an impediment to progresscomes down to your credibility in the enter-

3

prise. So, beyond these basics, you need tofigure out the best way to make your case interms your business and, in our case, your vicepresident of sales, can really understand.

Lessons Learned from Auto RacingConsider a simple analogy. The historic andgrueling 24-hour automobile race at Le Mans(24-Heures du Mans) runs every June inFrance. It tests hardware reliability, driverendurance, and team strategy. Arguably, oneconsiders a win at Le Mans the career pinna-cle for both an auto manufacturer and ateam of drivers. In the early 1960s, FordMotor Company decided to go racing withthe goal of winning at Le Mans, which meantdisplacing Ferrari, the powerhouse of thatera in GT racing.

As you might expect given its resources,Ford assembled a formidable team (or, indata center terms, a solutions frameworkwith legs and arms) composed of engineers,constructors, management, and drivers, withthe single objective of building a racing plat-form that would win Le Mans in 1964. Theresult was the legendary Ford GT40. ThreeGT40s were entered in the 1964 Le Mansrace. Although they performed well for their

The physical aspects of the framework including servers, end-userdevices, network components such as internal and external routes, andthe Telco-sourced broadband capacity needed to make it all work.

Operating system plus applications and firmware. Considerations includeunderstanding of network traffic generated by the software, open orproprietary sourced code, and data security plan.

The “How do I do this successfully?” component. Considerations include balanc-ing capability against the goals and service level agreements (SLAs) of yourextended ecosystem and time as a factor of expectations.

Quality assurance at the enterprise planning, organization, financialleadership, and controlling levels.

How does your baseline project management plan balance against theinternal skills required to complete this effort? What external resourceswill you need? How will you manage them?

Hardware

Software

Implementation

Management

Resourcing

Table 1. Foundations for a Cloud Solutions Framework


first time in competition, none finished therace. Ferrari’s cars finished in five of the topsix places. Hmmm. If the solution frameworklooked so good on paper, what happened?

Given the embarrassing end to what (atleast according to the solution framework)should have been an easy victory for Ford,the company took a slightly differentapproach moving forward. This time, whilemaintaining the fundamentals of the initialframework it used to build the GT40s, Fordreached out to a group of California hot-rod-ders. These hot-rodders not only appreciat-ed Ford’s original framework, but also under-stood elements outside the corporate worldthat Ford needed to align in order to win atLe Mans. In 1966, Ford’s GT40s placed first,second, and third—and then went on todominate the race for the next four years.

Cloud Solutions and Ford’s Desire for a WinYou may be wondering how this relates toa cloud solutions-based framework. It’s afair question. Remember our hypotheticalvice president of sales who had just con-tracted to implement a new cloud-based,outsourced customer relationship man-agement (CRM) system. (Think of this per-son as Henry Ford II, CEO of Ford from1960 to 1979.)

Our sales vice president has little concernabout a solutions framework. Instead, it’s allabout deadlines, budgets, resourcing, andselling more widgets with less overheadcost. Similarly, all Henry Ford II wanted outof his GT40 program was a victory at LeMans. Are you starting to see the parallels?

As Ford II found out in 1964, just pullingtogether a team (solutions framework) withthe right skills and components doesn’tmean your plan is fool-proof. Factors outsidethe framework can still ruin your plans. So, ifa core cloud solutions framework is more

4

In Henry Ford II’s case, it was simple. He stillhadn’t won Le Mans, so obviously the reali-ties of the broader framework impacted hissuccess in the 1964 race. He needed to findpeople who understood these realities andwere experts at linking core solutions into aviable delivery system.

For our sales vice president, the discussionmight also be this easy—since he’s likelymore plugged into the broader corporateecosystem than you are. This makes himmore aware of the “oopsies” that couldimpede the success of his new CRM system.Your role at this point is to simply remindhim about these considerations and helpwork through the potential impacts on hiscloud-based customer relationship manage-ment system. By helping him, you’re actuallyhelping yourself—and the enterprise.

Table 2 is a list of what those considerationsmight include.

As was the case with Ford in 1964, nobodyon the initial team wanted to reach beyondtheir comfort zone to suggest that it wouldtake a slightly different perspective to winLe Mans. I suspect the same might be trueof an IT or data center type who needs tobecome conversant in cloud framework con-siderations that don’t necessarily relatedirectly to technology. In my opinion, rightnow, you simply have no choice.

THE EIGHT FUNDAMENTAL TRUTHSThe eight cloud solution-based framework(CSBF) considerations we identified in Table 1,when viewed from a pure IT/data center per-spective, might be outside your comfort zone.While it’s true that these considerations aren’tgenerally about technology, ignoring them asyou implement any type of cloud architecture(private, public, or hybrid) is not an option—and doing so will result in failure. Given theexpansive nature of these CSBF considera-

tions—and the way they vary by geography,industry vertical, and the particulars of yourorganization—it’s not practical to try todescribe and address them all here.

Now we need to talk about corporate strate-gy. Consider Ford’s campaign to win Le Mans.Although flawed, the strategy was simple:match a powerful engine with a reliable drivetrain mounted on a strong chassis and pilotedby an accomplished driver. Ford’s linking ofengine to drive train to chassis to driver is anexample of a fundamental truth about whatit takes to win at Le Mans.

Boil It Down to the Core TruthsAs you consider the basis for your workablecorporate cloud strategy, you must also con-sider fundamental truths. In terms of thecloud, I consider a fundamental truth a princi-pal rule (or series of rules) that serve as thefoundation for the entire framework.Fundamental truths are inviolable.

What are the Fundamental Truths ofCorporate Cloud Strategy?We listed the eight fundamental truths thatform the cornerstone of a cloud corporatestrategy in the executive overview (page 1).Now let’s discuss them one at a time.

Fundamental Truth No. 1: It’s a JourneyHere’s our first fundamental truth of a corpo-rate cloud strategy: large-scale transforma-tion to cloud computing, including your criti-cal business systems, is a journey that willtake you from eight to 10 years.

Why does it take so long? Because, by itsnature, cloud computing is disruptive. Thisdisruption impacts your business, the waybusiness units work with each other, yourtechnology stacks (hardware and software),and, most importantly, your people and theirskill sets.


5

For your cloud strategy to work at an enter-prise (not just an IT/data center) level, youmust be able to understand and prioritizeyour business’s capabilities and repurpose oreliminate formally discrete and separatefunctions. This means your data center(s),networks (LAN, WAN, and wireless), applica-tion portfolios, end-user devices, and relatedbusiness processes must all be able to co-exist and work together in a way that theywere never designed for (at least since thedays of big iron). Also, it’s very likely that theway you determine direction in this evolvingenvironment will also change, which can essen-tially shift your corporate power structure.

To gain value from the cloud, you mustcompletely redefine your enterprise. Thismeans:

• Taking an entirely new approach tosuccess metrics, including new defini-tions and measurements. To do this,you’ll need to identify a baseline for com-parison to give the changes meaning.

• Radically changing your businessecosystems (skills, grade levels, respon-sibilities, and likely physical numbers) toadapt to the new normal.

• Taking an evolutionary versus revo-lutionary approach. Revolutions tendto be good for creating martyrs butnot so good for individual survival inthe typical enterprise.

Simply stated, history shows that disruptivechange of any type is adopted slowly. Whilesmall and medium businesses may have an

Where is your data stored? How do you access it? This varies by indus-try type, data type, and the legal requirements of your geography.

What are your company’s security policies, if any? What are your compa-ny policies surrounding matters of privacy? Are they linked somehow tosecurity concerns? If so, how?

Is your industry vertical trending toward shared data or islands of infor-mation? Is it well defined or undergoing significant changes that mightimpact how information is used and shared? What are the time framesprojected for these changes?

Is direction from the top, or is the cloud initiative driven by one or morecomponents of your business (which seems to be more the rule thanthe exception)?

How well do your business units work together? Does the culture meas-ure and reward performance from a functional level at the expense ofthe corporate level? What has been the history of success in cross-orga-nizational business initiatives? (Cloud requires a level of integration notseen since the days of the mainframe.) How does the corporation seethe value of your internal IT organization? (More than likely, you will betasked to convince everybody to play in the same sandbox.)

Can your company discuss how its enterprise architecture binds busi-ness with technology? Is standardization sort of adhered to, at least inspirit, or does your environment proudly support one of everything?

Implementing a cloud ecosystem, at any level, is disruptive. It forceschange down to the business and operational levels. How have thesetypes of actions been received historically in your enterprise? Is yourcompany risk-averse or risk-inclined?

Cloud is disruptive and requires your organization to consider:

• Establishing a balanced approach to effective service-level agree-ments (SLAs) based on business need as a factor of cost

• Recognizing that in a highly virtualized and geographically diverseoperating model, application oversight becomes extremely difficult

• Evaluating the skill sets required to manage this environment andbeing open to the suggestion that you may not have the talentyou need in your current organization

• Predicting, proposing, and anticipating a management responsebased on awareness of these challenges in your company’s historyand culture.

Geopolitical Requirements

Security/Privacy

Industry Direction

Corporate Strategy

OrganizationalCohesiveness

Enterprise EcosystemAwareness andStandardization

Willingness to EmbraceChange

Management

Table 2. Cloud Solutions-Based Framework Considerations


6

Why did General Robert E. Lee, commanderof the Army of Northern Virginia and GeneralLongstreet’s superior, order Pickett’s Charge?The reasons remain a mystery and aredebated even today. While the overall objec-tive of the charge was clear (removing theUnion forces from Cemetery Ridge), theUnion forces held all the advantages in thebattle. Victory would clearly be difficult—ifnot impossible.

You may wonder what a battle fought in theAmerican Civil War has to do with cloud com-puting. That’s a valid point. The answer circlesback to the second of our eight fundamentaltruths of corporate cloud strategy: cloud is atop-down architectural framework that bindsstrategy with solutions development.

At a macro level, Intel IT views architectureat three levels, with each succeeding leveldefining and validating the actions of its suc-cessor (Table 3).

In a perfect world, where strategy is alwaysdefined by a smooth flow of business planningbacked by infallible leadership, the modelshould work well. Unfortunately, as Pickett dis-covered, this isn’t always the case. Arguably,the decision to engage in a frontal assault onthe Union fortifications on Cemetery Ridgeoffered a direct solution to a problem.

Whether General Lee tactically considered theassault as part of something more strategic isa point argued by military historians.Unfortunately, and as shown by the cata-strophic outcome, the loss of troops was sogreat in this one battle that the Confederacynot only lost the Gettysburg campaign, but itnever recovered. Does this outcome validateour conclusion that if one element of anenterprise strategy changes, it automaticallyimpacts the others? It’s your call.

The longer-term (usually 18 months to five years) articulation of thecontext, priorities, and plans that set the boundary conditions and roadmap for developing a tactical architecture over a prescribed time period.Conceptual in nature, it comprehends the high-level roles, capabilities,and processes to achieve the end state. It is the most abstract of thearchitectural types, with a goal of establishing strategic direction.

Provides a template solution for an architecture specific to a particulardomain. Its aim is to stress commonalty in areas such as vocabulary,boundaries, and guidelines to promote:• Integration• Standardization• Reuse

Reference architecture is characterized by a medium level of abstraction,with the goal of identifying and standardizing solutions. Its artifacts form astarting point for solution architecture development. These may range fromarchitectural patterns, mechanisms, and frameworks to complete systemswith known characteristics. They may be applicable for a broad class of sys-tems spanning domains or have a narrower focus.

Describes the scope and design of a change in business functionality.These are normally used to constrain and guide program/project designand implementation. The solution or service architecture is not con-strained to changes only; in some cases, it can identify a gap and devel-op a solution to improve the efficiency of existing/ongoing businessfunctionality.

A solution architecture must align with the strategic architecture andshould reuse or align to the reference architecture as much as possible.

Service architecture is an architectural strategy that aims to isolate andseparate the consumption of business functionality from the provision-ing of a function through commonly-defined service contracts.

Strategic

Reference

Solution/Service

Table 3. Intel’s Architecture Types

advantage in their ability to adapt andrespond quickly to a cloud strategy, the wildcard is an organization’s ability to respond tochange (with people as the biggest concern).

Fundamental Truth No. 2: Top-DownArchitectural FrameworkOn July 3, 1863, at around 2:30 p.m., 13,000Confederate troops—under the command ofGeneral James Longstreet and led by divisioncommanders J. Johnston Pettigrew andGeorge Pickett—began an infantry assault onheavily-fortified Union positions on CemeteryRidge. The assault, known as Pickett’sCharge, required the Confederate troops to

cross three-quarters of a mile of openground in an area surrounded by elevatedUnion artillery (which is tactically not sogood). It occurred on the third day of theBattle of Gettysburg, a pivotal battle in theU.S. Civil War.

Pickett’s divisions had the unenviable role ofbeing ordered to lead a direct frontal assaulton the Union positions. As was sadly pre-dictable, Pickett lost about 3,000 men (morethan half of his division, including all 15 regi-mental commanders) and failed to achievehis objective.


7

The Innovation Value Institute’s (IVI) IT-CapabilityMaturity Framework for Enterprise ArchitectureManagement suggests that to build an effectiveEA, you must be able to measure the maturity ofpeople, planning, and practices. Maturity is meas-ured against things like framework, process,value, governance, planning, organizational struc-ture, skill sets, and communications.

Success Depends on EA MaturitySo, in terms of expectations for cloud execution inyour organization (and with the caution that I con-sider mission-critical applications when I say this),your success, and likely your return on invest-ment (ROI), are very much linked to the maturityof your EA. If you’re a somewhat immature organ-ization, your cloud framework will likely reflectelements of this immaturity.

Fundamental Truth No. 4: Services-Oriented Enterprise TaxonomyBesides my family (and, of course, Intel), Ihave three passions. One is high-perform-ance aircraft (current generation to early

The Forrester white paper we mentionedearlier concludes that end users (called infor-mal buyers) drive cloud IaaS adoption. Theseinformal buyers are focused on solution-levelstrategy. Enterprise strategy isn’t their con-cern. It’s like what happened during Pickett’sCharge. A data center/IT organization’s abili-ty to navigate the difficult open groundbetween a business-unit-based cloud solu-tion and a more strategic perspective comesdown to factors of leadership, relationshipswith business groups, and, to a degree, sim-ple luck.

Fundamental Truth No. 3: The Cloud EcosystemI recently participated in a meeting of Intel’sEnterprise Board of Advisors (EBOA) DataCenter Working Group. During the call, one ofthe members—from a very large, multi-nationalcompany headquartered in Europe—mentionedthat in their experience, cloud is more a changein process than a change in technology.

That made me think of our third fundamentaltruth of cloud computing strategy (and theone we’re discussing today): your cloudecosystem is only as robust and adaptableas the sum of its parts.

If a stranger asked you to describe your busi-ness from end to end in 30 seconds, whatwould you say? You might describe it interms of its enterprise architecture (EA),which can be a good way to understand yourcompany as a series of connected parts.

According to Wikipedia, EA is “a rigorousdescription of the structure of an enter-prise, which comprises enterprise compo-nents, the externally visible properties ofthese components, and the relationshipsbetween them. This description is compre-hensive, including enterprise goals, busi-ness processes, roles, organizational struc-tures, and organizational behaviors.”

Although there are variations used todescribe the components of EA, I prefer touse those included in a framework known asThe Open Group Architecture Framework(TOGAF), which includes four related but dis-tinct architectural components. Table 4shows how we describe them at Intel.

The robustness of an EA framework—bydefault, any activity such as cloud that requiresuse of these architectural components—isdetermined by an organization’s ability to use it.The robustness of your EA is generally meas-ured as a factor of maturity. In mature organi-zations (defined on a 0 to 5 scale), the EAframework is a key component of success thatlinks the value of the IT organization to theobjectives of the enterprise. In practice, though,your EA maturity can (like the attractiveness ofyour own reflection in the mirror) be hard tomeasure objectively.

The business architecture serves as the interface between the needs ofthe enterprise as reflected in its work and the IT solutions that facili-tate that business. The business processes serve as the foundation fora number of important architectural decisions in the balance of theenterprise architectural domains.

The data architecture is intended to promote information sharing andreuse in support of business processes across the enterprise. This isdone via standard description and discovery of common data and thepromotion of uniform data management practices.

Specifies the key elements of information systems used in executing itsbusiness processes. These elements include the services taxonomy and itscomponents. They represent the organization’s application portfolio andidentify the business systems that enable and support the execution ofIntel’s business processes (outlined in the business architecture). The appli-cation architecture provides a cross-reference of capability or service.

Describes current and future technology infrastructure and specifichardware and software technologies that support your corporate infor-mation systems. It provides guidance and standards for implementingtechnologies that are proven to work well with existing and plannedtechnologies.

Business

Data

Application

Technical

Table 4. TOGAF Architecture Types

8


the cloud promise includes a commitment tocutting both costs and the time it takes torespond to business change.

If you compare the overall promises of thecloud to the architectural goals of a services-based taxonomy, you might see some similar-ities. This is where the discussion becomesharder. If you look at the success and historyof various service-oriented infrastructureand architecture (i.e., service-oriented infra-structure [SOI] and service-oriented architec-ture [SOA] efforts), you’ll likely find a recur-ring theme I refer to as the “field of dreams.”If you remember the excellent movie of thesame name (it helps if you’re a baseball fanwhose roots are in Chicago), it’s about anIowa corn farmer who hears voices that tellhim to build a baseball diamond in his fields.He is spurred on by this message: “If youbuild it, they will come.”

Unlike the movie, where “they” (the old-timeplayers of the farmer’s dreams) did comeafter the ball field was built, many enterpris-es began the SOI/SOA journey only to findout that it was significantly harder than theyexpected. As the Figure 1 shows, there’s alifecycle you can associate with migrating toa services-based framework. In my experi-ence, not many organizations actuallyreached the service catalog stage. Thosethat did, in general, had a hard time sustain-ing the effort.

1930s); the second is just about anythingpowered by an internal combustion engine.My third passion is an insatiable desire tounderstand the history of both. For thosewho know me personally, this revelation isnot much of a surprise. Once again, I willattempt to make a point about the cloudusing historical analogies from the automo-tive vertical.

Henry Ford and Service-OrientedTaxonomies?So, what exactly does Henry Ford’s Model Thave in common with my fourth truth of cor-porate cloud strategy: services-oriented tax-onomy is not optional?

Ford’s Model T became available in 1908. Due toits low initial price (USD 950), demand was brisk.When Ford’s auto first went into the market-place, it was assembled by a team of two orthree workers who would collect the parts theyneeded and start the assembly process. If a partdidn’t fit, they used hammers, crowbars, files,and plain old brute strength to coerce it intoplace until they had formed the end product.(Think of it as a service.)

There were two fundamental problems withthis approach. First, the time and labor ittook to complete each Model T varied. Thesecond issue involved service life cycle con-siderations. If something breaks, and if everypart is unique, how do I fix it? And what willit cost to repair?

Henry Ford’s response to these problemsboiled down to standardization and inter-changeable parts. Every piece became exact-

ly the same as its successor and predecessorand fit with all the others into sub-assem-blies (i.e., building blocks). In a sense, themanufacturing methods Ford used for theModel T were the great-grandfathers of aconcept that we refer to as a services-basedarchitecture framework.

At a strategic level, a service-based architec-ture framework has four layers:

1.) Defining and coordinating businessprocesses and workflows

2.) Replacing functional silos with networksof services

3.) Policy-based, distributed, and automatedmanagement

4.) Building blocks (grouped into servicecatalogs) that provide a cost-effective,standardized set of capabilities for busi-ness process execution, user experi-ence, governance, security, manage-ment, communication, and virtualization

Cloud Expectations: Cut Costs and Time to DeliverWith that foundation, let’s briefly revisitsome of the promises of the cloud. Althoughdefinitions vary greatly, cloud computing isgenerally considered to be the delivery ofinformation capabilities (i.e., technical infra-structure, applications, or services) over theInternet by third-party-managed data cen-ters. Today, cloud business models includesoftware-as-a-service (SaaS), platform-as-a-service (PaaS), and IaaS—all delivered via pri-vate, hybrid, or public frameworks. Part of

(noun) than it really is. (Maybe I should makethat “cloud,” since a recent Wall StreetJournal article concludes that branding gurus,particularly in Silicon Valley, tend to favordropping articles such as “the,” “an,” or “a”before a noun because they believe thatwithout it, the word assumes an almost anicon-like aura. )

What CIOs Are SayingTo see my point, look at Figure 2. Intel oftensends me to events where a broad range ofindustry CIOs discuss their perspectives on, andstrategies for, the cloud. From these discus-sions, I’ve constructed a graphic that identifiesrecurring themes and shows some of the pro-found differences in how the industry viewsthe cloud as a noun versus a verb.

Cloud Necessitates That You Think BigWhat should capture your immediate attentionin the figure is the imbalance in the columnwhere cloud is viewed as a noun. Obviously,the cloud encompasses much more than thedata center and a thin client. If what I’m seeingis accurate, it’s not clear why this is happening.Perhaps it indicates factors the CIO can control.Perhaps it’s a response to the way the cloudseems to be finding its way into the enterprise.Regardless, I seem to spend a significantamount of time promoting these two ideas:

9


the general mechanics of the English writtenword. In fact, my constant companion is the1971 edition of Practical English Handbook.

So, having admitted one of my darkestsecrets, it’s with some irony that I discuss myfifth truth of corporate cloud strategy: cloudis a verb, not a noun.

Deeper Meanings to Our TerminologyFirst, let’s look at the meanings of “noun”and “verb.” According to Webster’s NewWorld Dictionary of the American Language,a noun is any of a class of words naming ordenoting a person, place, thing, event, sub-stance, quality, quantity, or idea (e.g., boy,water, truth). Conversely, a verb is any of aclass of words expressing action, existence,or occurrence (e.g., bring, read, walk, run,learn), or a state of being (e.g., be, exist,stand). While you may find these definitionsmildly informative, why should you care?

I tend to believe in common sense over spec-tacle—and to assert that moving to the cloudis a complex process that takes the align-ment of many moving parts. In other words,the cloud is more of a verb than a noun.

Unfortunately, the industry seems intent onmarketing “the cloud” as more of an object

I don’t envision the evolving cloud frame-work as absolute in a typical enterprise.More likely, and driven by data security con-siderations, it will evolve as a blend of busi-ness applications delivered:

• From both the public and private cloud

• Through traditional infrastructure

Given this scenario, integrating services (e.g.,business process execution, user experience,governance, security, management, and com-munication) will be a necessity. While it maybe possible to handle this integration on acase-by-case basis, I’m quickly brought backto Henry Ford’s Model T and the disadvan-tages of custom-fitting each component ofthe architecture to the next. I simply don’tsee a clear path for cloud to fully deliver onits promise without some kind of services-based architecture running on the back endof the enterprise.

Fundamental Truth No. 5: Cloud is aVerb, Not a NounLet me begin with an admission. Ever sinceMiss Jacobson’s seventh-grade English classat Lincoln Junior High School, I’ve recognizedmyself as somewhat challenged in the prop-er use of commas, adjectives, pronouns, and

Figure 1. The Evolving Cloud Framework

1.) The cloud is much bigger than the data center.

2.) You must develop an end-to-end strate-gy if you hope to be successful.

Regarding the belief that the cloud somehowalways leads to a thin client, it’s alwaysinteresting when I ask an enterprise howthey used considerations like applicationarchitecture (driven by usage models), dataarchitecture (network packet sizing), andassociated bandwidth considerations (wiredand wireless) in reaching that conclusion.More often than not, I either get no answerto my questions or the subject is changed.

To sum up, it’s entirely possible that my views onwhether the cloud is more often thought of as anoun than a verb are wrong. As I’ve said, I basedthem on discussions with Intel customers andother CIOs at industry events.

Fundamental Truth No. 6: GovernmentRegulationsI recently finished the third book of EdmundMorris’ trilogy on Teddy Roosevelt, ColonelRoosevelt. In the book, a reporter for the NewYork Times says the muted reaction to manyof Roosevelt’s speeches denoted not so muchapathy as “a quiet, steady, intent earnestnessthat does not often characterize a crowd....”Hey, that’s good enough for me.

With this thought in mind, let’s consider thesixth fundamental truth of corporate cloudstrategy: technology-driven business prac-tices often circumvent government regula-tions, but legal and government policy stan-dards will dictate the cloud’s success.

Based on everything I see and hear aboutworldwide cloud implementation, this topic isthe most important of our eight truths. Tobegin the discussion, look at Figure 3.

Figure 2. Cloud as a Nounverus a Verb

Figure 3. Intel’s Cloud2015 Vision

10


“One of the things often lost in theindustry’s discussion about the cloud isthat there is a physicality underlying thecapability.” Privacy, like all cloud policyconsiderations, is under the jurisdictionof the originating geography. Given thatthe cloud is a community-based ecosys-tem, how can you protect data privacy(whose definition varies from communi-ty-to-community) in a cross-jurisdictionalenvironment?

• Competition and standards. Whileinternational bodies (e.g., IEEE) pursueglobal standards, there are many morethat shape standards along geography-based interests. Based on conclusions inthe Asia Cloud Manifesto, rapid stan-dardization in one ecosystem has thepotential to lock out new standards andlimit the actions of players outside theecosystem. In short, the likelihood ofconflicting national standards increasesas these geo-based consortia propagate.

• Bandwidth management (wired andwireless). This topic is so significantthat we will discuss it separately in alater section.

• Sovereignty. When asked about a reci-procity agreement with Canada on July21, 1911, Teddy Roosevelt said,“Economic considerations mattered less inforeign negotiations than those ofnational pride.” What was true then stillholds today. No universal rules or legisla-tive framework take precedence wheremultiple jurisdictions have an interest in asingle matter. For a cloud ecosystem,jurisdiction over data is potentiallyasserted based on location of the serviceprovider, user, and server.

In my opinion, some of the most open think-ing about the global implications of policyand standards on the cloud is coming out ofacademia. Maybe this is because the academ-ic community, by its nature, is a group ofexperts aligned along areas of interest ver-sus geography.

Cloud Computing in AsiaIn November 2010, Keio University, Japan’sfirst private institution of higher learning,published the Asia Cloud Manifesto. The doc-ument explores the implications of cloudcomputing across Asia and begins to addresspotential impediments to the regional coop-eration it will take to establish a robust cloudecosystem. A key element of the discussionis identifying policy- and standards-relatedissues that apply to the cloud in Asia. For me,the most compelling aspect of the Manifestois that these issues are universal.

Based partially on the Manifesto, and in noparticular order, here are what I consider thetop-tier policy and standards considerationsfor the cloud:

• Privacy

• Competition and standards

• Bandwidth management (wired andwireless)

• Sovereignty

• Copyright

• Security (logical and physical)

Policy and Standard Considerations• Privacy. Let’s start this discussion with

an idea sparked by a comment I receivedfrom Brad Ellison (a senior data centerengineer for Intel IT). Brad believes,

While Intel’s 2015 cloud vision is an interest-ing discussion on its own, the implicationsand limitations of the broader cloud vision, asrelated to policy, become apparent if youconsider the world map I’ve included in thebackground.

Let me explain. A robust cloud framework(private or public) is community-oriented byits nature. This includes not just select partsof the community, but the entire ecosys-tem—hardware, data, process, communica-tions, and skills. By considering that the cloudcommunity, at least from a technology per-spective, has the potential to include everycountry on the planet, you begin to get asense of why I consider the discussion ofcloud policy so important.

Governments Impacting CloudFrom this point on, we must consider howcloud technology—and, by default, any of ourbusiness systems and related data hosted inthe cloud—must contend with policies andstandards that are framed by location andrelated geopolitical considerations.

In an October 1, 2011, Washington Post col-umn by Lillian Cunningham, Google’s EricSchmidt recalls a dinner in 1995 with Intel’sco-founder Andy Grove. When asked aboutgovernments’ ability to react to technologicalchange, Andy said that “…high tech runsthree times faster than normal businesses.And government runs three times slowerthan normal businesses. So, we have a nine-times gap.” Although the comment was pri-marily about government in the U.S., govern-ments worldwide have a similar cadence.Given government’s role in establishing andimplementing cloud policy and standards, thisis an interesting conclusion.


11

12


How this consideration ultimatelyimpacts marketplace access via a cloud-based community is (at least in my hum-ble opinion) the key element for theentire business model.

• Copyright. How is this considerationapplied uniformly, worldwide? How doyou protect your company’s patents oran individual’s intellectual property (IP)?How do intermediaries deploy filteringfeatures that comply with the appropri-ate jurisdiction’s rule of law (see thesovereignty discussion above)? Whathappens if there’s copyright infringe-ment? Who bears financial liability—theservice provider, service broker, or thecountry where the IP violation occurred?

• Security (logical and physical). There’san obvious link between security andprivacy, which is perhaps best describedby a comment made by Ed Goldman,Intel IT CTO and general manager for ITstrategy, architecture, and innovation. Ina discussion we had on cloud security,Ed stated that “Privacy advocates desirethat less data be retained about individ-uals (no matter if they want the person-alization capacity which requires lots ofdata about them) and security advo-cates want us to keep more (to investi-gate and resolve). As we ensure bettersecurity, it comes at the cost of privacy.Conversely, enabling more privacy con-trols comes at the expense of our abilityto identify security risks and customerdemands.” There are many geography-based security standards that compoundthis challenge, none of which apply end-to-end.

Government Policy Initiatives SamplerThere are cloud initiatives and strategiesdeveloped in the United Kingdom, Germany,Finland, France, Japan, and Taiwan and

lanes), you’ll likely go at a pace that is…well,let’s just call it “leisurely.”

This may not be a perfect analogy, but navigat-ing through LA on The 405 seems an apt wayto start discussing our seventh fundamentaltruth of cloud computing: bandwidth and datatransmission may not always be as inexpen-sive and unencumbered as they are today.

As we discussed in the previous section,bandwidth management is one of six govern-ment-regulated policy and standards consid-erations that you (and your cloud provider)must understand as you continue your jour-ney to the cloud. Since every governmenthas its own approach, the best advice I canoffer is to balance your goals against yourgovernment’s related policies. One size defi-nitely does not fit all.

Broadband Spectrum ConsiderationsTo begin, it’s key to recognize that the broad-band spectrum is a shared resource.

As a consumer, I expect that everyone in myhousehold, on any number of devices, cansimultaneously download a live video streamof our favorite movies or TV series, haveinstant audio and video chats, and keep trackof our stock portfolios—all while playing videogames. I also expect latency of less than 100milliseconds and costs that I consider “fair,”with anything more being an example of theprovider getting rich at my expense.

As a business, I understand cloud computingrequires data center broadband connectivityto any number and/or type of devices,including those that can only receive data(zero/thin client). Further, these ecosystemsmust provide service and reliability thatmeets the specific needs of my business. Forexample, healthcare and command and con-trol systems demand reliability and lowlatency. Considering my quality of service

throughout the European Union. I’ve listedsome of them below. I don’t intend this tobe an exhaustive summary of all existingor draft legislation for all geographies.Instead, I hope it demonstrates the poten-tial challenges imposed on a robust cloudecosystem by non-aligned, geographically-based policy initiatives.

• European Union

• Electronic Commerce Directive

• Data Protection Directive

• United States

• Cloud Computing Act of 2011 (draft)

• Digital Millennium Copyright Act

• Communications Decency Act

• U.S. Patriot Act

• FCC Ruling on Net Neutrality

• Sarbanes-Oxley

• Japan/Some Parts of Asia

• APEC Data Privacy Pathfinder Project

Fundamental Truth No. 7: Bandwidthand Data TransmissionLike so many people around the world, youmay have visited Los Angeles at somepoint—if only for the weather. Whether yourvisit was for business or pleasure, you likelydrove on what we Californians call The 405(also known as the San Diego Freeway).Separating greater Los Angeles from beachcommunities like Malibu, Santa Monica, andRedondo Beach, The 405 is among the topfive most congested freeways in the U.S.With its last upgrade completed in 1969, The405 just wasn’t designed to accommodatetoday’s traffic flow. While you can make for-ward progress (assuming no accidents orobstacles are blocking any of the 12 traffic

13


and reliability needs, I expect to pay accord-ingly but need the provider to disclose mean-ingful data such as service terms, pricing(perhaps based on volume rather than time),packet loss, delay, service availability rate,and SLA-based response time (latency).

Evolving Revenue ModelsWith all of this in mind, it’s likely the revenuemodels for broadband services (which varygreatly from geography to geography) will soonchange. At a Telco 2.0 conference earlier thisyear, I saw the chart shown in Figure 4.

Figure 4 suggests that by 2016, there will bearound 15 times more mobile traffic thanthere is today, primarily driven by video (thisis the traffic on the access side). More recentvideo traffic projections suggest this numbermay be conservative.

Historically, switched voice has been the cashcow for telecommunication companies. But asthe image suggests, the projected growth inthis traffic is flat. The company presentingthe slide stressed that today’s broadbandfees are assessed based on time instead ofnetwork volume used.

Huge Amounts of Data Are FlowingOver NetworksAs the conference attendees discussed thisslide, an implied consensus emerged: thismodel will likely change because of the bur-

tion portfolio and ending with the selection ofintelligent end user devices—to at least have atacit understanding of how these topics may ormay not impact your costs and success.

Fundamental Truth No. 8: AltruisticModels Don’t Keep the Lights OnThe goal of every publicly traded company isto deliver value to its shareholders. From asimple financial perspective, and with theexception of non-profits, this value is meas-ured in terms of profitability and customer andemployee satisfaction. Of the three, profitabili-ty seems to make shareholders the happiest.It’s generally a company’s line of business(LOB) groups, where the products or servicesare developed, that generate these profits.

ProfitabilityIt’s this last point I was thinking about when Iset out the eighth and final fundamental truthof corporate cloud strategy: altruistic motivesdo not generally keep the lights on.

Let’s face it. If you’re reading this white paper,chances are good that if I asked somebody inyour LOB area about your business knowledge,they would either laugh or ignore me. If thisweren’t true, why, after 30-plus years ofessentially the same dialogue, do we still haveto argue whether IT has any business value?

I’d also bet that if I asked the same peoplewhat you or your group contribute to the prof-itability of the company, most would say theysee lots of money going into IT but nothingmuch of value coming out. Right or wrong, youall face the attitude of the fictitious sales wediscussed earlier.

Again, you bring to the party a perspectivethat your LOB person doesn’t have. And youcan use this skill, as the world strugglesthrough the area of the cloud hype cycle thatGartner calls the “Trough of Disillusionment,”to lead your company through the chaos ofbroad adoption (assuming your voice is heard).

geoning amount of data transmitted over thenetworks (both wired and wireless).

There is some evidence that these changesare already happening, at least in the U.S. InMay 2011, one of the large U.S. carriers beganimposing monthly data limits for its fixedbroadband subscribers. With U.S. consumersseeing broadband as described above, themove was highly unpopular. Again, it’s perhapssafe to conclude that tiered pricing packagesof some sort—based on how much data is con-sumed or how fast the data is delivered, or apossible hybrid of both—will evolve over thenext few years. Can I state this with absoluteassurance? No. But then again, if there is achance of it happening, how do I mitigate therisk to my company—particularly if I’m justify-ing the cloud based on ROI?

Another topic of some importance in the U.S.(primarily because, as I understand, it has nojurisdiction over wireless providers) involvesnet neutrality. Net neutrality is fundamental-ly about data capping. With an admission thatthis discussion is best left to attorneys, it’sstill safe to conclude that you and your cloudservice provider need to at least be aware ofwhat’s happening under this umbrella.

To me, it seems prudent to anchor anyexpansion of business activity in your cloud—beginning in your data center and extendingto how you design your cloud-based applica-

Figure 4. Mobile Traffic(2008 – 2016)


14

you’re on the offense, what are you doingtoday, within your larger organization, toremove the emotion from these types of dis-cussions and to force an unbiased financialfocus on the realities of your environment? It’salso critical to recognize that in some cases,outsourced and cloud-hosted applications willsave your company money and boost profit.How will you discuss these instances?

Next, recognize that every CSP is differentand that they, like every other component ofthe cloud ecosystem, are not altruistic. Tostay in business, they must be profitable inthe long term. While it’s not your job tounderstand the details of how they makemoney, it is your job to understand how theirpursuit of profit will potentially impact theservices provided to your company. Althoughthis isn’t an exhaustive list, we can infersome indicators by looking at how theyensure delivery of services:

• What are the procedures for monitoring/report-ing SLAs, maintaining global government policycompliance, and securing data?

New OrderTo begin this part of the discussion, reviewFigure 5.

First, using the profitability goals of eachcomponent of a typical end-to-end publiccloud ecosystem as a baseline, take an archi-tect’s perspective of the process. Once youdo this, you begin to appreciate the chal-lenges ahead—and the unique perspectiveyou bring to the solution.

Next, confront the conflicting profitabilityexpectations within your own enterprise. Aswe noted in our discussion of the mythicalsales VP, his or her first concern is profitability.From their perspective, reducing your foot-print—based on the promises made by thecloud service provider (CSP)—is a way to boostprofit without losing anything. Sometimes thisis true, but other times it’s not.

Playing Offense or DefenseAt this moment, you have a choice. Do youtake an offensive or defensive strategy toconfront your contribution to profitability? If

Common SenseYou may have led or participated in a largehardware migration project or a major appli-cation development effort. Was the experi-ence akin to herding cats, with each productand/or vendor representing a cat thatabsolutely had to move in the same directionfor the effort to succeed? How did you man-age the herd through the hardware or sys-tem’s lifecycle? Were you, like me, alwaysimpressed with how quickly these cats, whensomething started going south, always knewit was another cat’s problem?

Grudgingly, though, we all know the reasonfor the drill. Each cat is responsible for itsown interest’s profit. Time spent chasingand fixing problems impacts their ability toreach that goal. Unfortunately, as the ulti-mate stakeholder in this relationship, wewere the ones held accountable to fix theproblem. This experience is the source ofthat unique perspective I mentioned earlierand which will be of significant value in theevolving cloud ecosystem.

Figure 5. Ecosystem Drill-Down: Public Cloud

About the AuthorBob Deutsche joined Intel in 2004 and has more than 25 years of business and IT experience in positions that rangedfrom data center operations to software development to CIO. You can read his regular columns at Data CenterKnowledge and in the Server Room in Intel’s Open Port Community.

15


series into a single and easily accessiblesource. I hope with this white paper we’vefulfilled these requests.

To continue the discussion, contact methrough Data Center Knowledge or theServer Room in Intel’s Open Port Communityor send email to [email protected].

Find the solution that’s right for yourorganization. Contact your Intel represen-tative, visit Intel’s Business Success Storiesfor IT Managers (www.intel.com/itcases-tudies), or explore the Intel.com IT Center(www.intel.com/itcenter).

er fall a bit short if you consider topics likeintelligent edge, radio access, and broad-band access networks. Right now, though,it’s hard to predict how this businessmodel will play out other than to recognizethat changes are imminent. The bestadvice I can offer is to ensure someone inyour organization is assigned to monitoractivity in your geography.

CONCLUSIONSThe response to my eight fundamental truthsof enterprise cloud strategy has been gratify-ing and so have the resulting discussions. Aspart of these discussions, I’ve had a numberof requests to consolidate the entire blog

• Do they have an audit process? If so,what standard is it based on?

• What is their level of assumed indemnity(first and/or second)?

• Do they support an open architectureif that is important to your corporatestrategy?

Finally, how do the Telcos end up playing inthis space? This varies from country tocountry, and we are beginning to see atrend where they are assuming the dualrole of data center and network cloudservice provider. If this trend continues,the evaluation criteria we mentioned earli-

Copyright © 2012 Intel Corporation. All rights reserved.

Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and/or other countries.

*Other names and brands may be claimed as the property of others.

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE,TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCHPRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OFINTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OFANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.

A "Mission Critical Application" is any application in which failure of the Intel Product could result, directly or indirectly, in personal injury or death. SHOULDYOU PURCHASE OR USE INTEL'S PRODUCTS FOR ANY SUCH MISSION CRITICAL APPLICATION, YOU SHALL INDEMNIFY AND HOLD INTEL AND ITS SUB-SIDIARIES, SUBCONTRACTORS AND AFFILIATES, AND THE DIRECTORS, OFFICERS, AND EMPLOYEES OF EACH, HARMLESS AGAINST ALL CLAIMS COSTS, DAM-AGES, AND EXPENSES AND REASONABLE ATTORNEYS' FEES ARISING OUT OF, DIRECTLY OR INDIRECTLY, ANY CLAIM OF PRODUCT LIABILITY, PERSONALINJURY, OR DEATH ARISING IN ANY WAY OUT OF SUCH MISSION CRITICAL APPLICATION, WHETHER OR NOT INTEL OR ITS SUBCONTRACTOR WAS NEGLIGENTIN THE DESIGN, MANUFACTURE, OR WARNING OF THE INTEL PRODUCT OR ANY OF ITS PARTS.

Software and workloads used in performance tests may have been optimized for performance only on Intel microprocessors. Performance tests, such asSYSmark and MobileMark, are measured using specific computer systems, components, software, operations and functions. Any change to any of those fac-tors may cause the results to vary. You should consult other information and performance tests to assist you in fully evaluating your contemplated purchas-es, including the performance of that product when combined with other products. For more information go to http://www.intel.com/performance.

Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics ofany features or instructions marked "reserved" or "undefined". Intel reserves these for future definition and shall have no responsibility whatsoever for con-flicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with thisinformation.

The products described in this document may contain design defects or errors known as errata which may causethe product to deviate from published specifications. Current characterized errata are available on request.

Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing yourproduct order.

Copies of documents which have an order number and are referenced in this document, or other Intel literature,may be obtained by calling 1-800-548-4725, or go to: http://www.intel.com/design/literature.htm

0212/SS/BD/PDF

Documents

The Eight Fundamental Truths of Enterprise Cloud Strategy › content › dam › www › public › us › en › ... · Cloud Computing The Eight Fundamental Truths of Enterprise