Why We Fail: How an architect learned to stop worrying and love the cloud

14
(or how an architect learned to stop worrying and love the cloud) 1 Alex Jauch @ajauch linkedin.com/in/ajauch

description

Private cloud has been the “up and coming” trend for several years. You would think this would mean we’re all running clouds inside our firewalls by now. In reality, this hasn’t happened. Why? Where are all the clouds? All the technical skills that the IT folks need to get this done are normally in house or easily accessible to them. So you would think that private clouds would be super common. Turns out they are not. Only a very small minority of IT organizations have deployed successful internal Private Clouds. There are notable exceptions, but they’re just that, exceptions. Why is this so hard? Why can’t folks get this done in their sleep? In this book, we will explore the reasons why we fail and how to overcome these obstacles to success in our private cloud deployments.

Transcript of Why We Fail: How an architect learned to stop worrying and love the cloud

Page 1: Why We Fail:  How an architect learned to stop worrying and love the cloud

(or how an architect learned to stop worrying and love the cloud)

1

Alex [email protected]/in/ajauch

Page 2: Why We Fail:  How an architect learned to stop worrying and love the cloud

Why Am I Giving This Presentation?My Background is Enterprise IT

12 Years at MSFT

Role Owner for Architect Career Path

Founder of Catalyst, Precursor to MCA

Lead Architect for NetApp’s MSFT Private Cloud Solution

Last Two Years on Private Cloud Space

2

Page 3: Why We Fail:  How an architect learned to stop worrying and love the cloud

What is A Cloud?The Term “Cloud” has little meaning in practice

However, everyone wants “Cloud”

IT Organizations Seek to Implement “Cloud”

Definitions Vary

3

Page 4: Why We Fail:  How an architect learned to stop worrying and love the cloud

So What? Gartner: 78% of Enterprise IT

Shops will Deploy a “Private Cloud Computing Strategy by 2014”

CIO.COM: 62% of all IT Projects Fail

Cisco: 52% of Cloud Projects Driven Top Down

Only 30% Driven by Customer Requirements

A high percentage of all IT projects fail. Combine this with the likelihood that most IT shops will deploy private cloud and the complexity of cloud means a high likelihood that most IT shops will fail at cloud.

Page 5: Why We Fail:  How an architect learned to stop worrying and love the cloud

The NIST Cloud Definition Framework

DeploymentModels

Service Models

EssentialCharacteristics

Common Characteristics

Software as a Service (SaaS)

Platform as a Service (PaaS)

Infrastructure as a Service (IaaS)

Resource Pooling

Broad Network Access Rapid Elasticity

Measured Service

On Demand Self-Service

Low Cost Software

Virtualization Service Orientation

Advanced Security

Homogeneity

Massive Scale Resilient Computing

Geographic Distribution

Community CloudPrivate Cloud Public Cloud

Hybrid

Clouds

The NIST Cloud Definition Framework provides a simple way to define what cloud is. This is hugely important for architects. We must first define what it is we are building if we are to increase our chance of success.

Page 6: Why We Fail:  How an architect learned to stop worrying and love the cloud

Why We Fail

The essential element of “cloud” is a customer centric business model, not technology.

The Majority of IT organizations approach private cloud as a technology problem.This is a failure in Architectural practice.

6

Page 7: Why We Fail:  How an architect learned to stop worrying and love the cloud

What Is Architecture?

7

Architecture is the intersection between business and technology. When given business requirements, the architect produces functional specifications; when given technical capabilities, the architect produces solutions.

Page 8: Why We Fail:  How an architect learned to stop worrying and love the cloud

Reducing Your Risk

There are two types of risk: Business and Technical. Most of us focus the majority of our time on technical risk. However, the primary risk to cloud implementations is not technical, it’s business. This lack of focus causes failure due to inattention.

Page 9: Why We Fail:  How an architect learned to stop worrying and love the cloud

Which Column Are You In?

9

IT Creates and Manages Budget

End User Departments Create and Manage Budget

IT Sizes Solution End User Sizes Solution24-48 Hour SLA for Provisioning

5-10 Minute SLA for Provisioning

0 RPO/15 Minute RTO 15 Minute RPO/24 Hour RTO

Guest Patching Policy No Guest Patching Policy

Defined List of Applications

Unlimited Applications

Advanced Capacity Planning

On-Demand Capacity

Strict Performance SLA Loose Performance SLAStrict Security Policy Loose Security PolicyLeast Privilege Model Full Privilege ModelIT Supported VM’s End User Supported

VM’s

Before designing and deploying a cloud, you must first ask yourself if you want to be in the cloud business or not. The column on the left describes a typical legacy IT environment where IT exercises control to protect the business from technical risk. The column on the right describes a typical cloud business such as EC2 or Azure.

Page 10: Why We Fail:  How an architect learned to stop worrying and love the cloud

Legacy IT Doesn’t Work

10

Why build a freeway if you don’t have any cars?

That’s what North Korea does.

Page 11: Why We Fail:  How an architect learned to stop worrying and love the cloud

Capitalism is MessyThe reality is that centrally planned economies just don’t work. Consumer focused economies work. We know this from the last fifty years of history. Communism (or rather totalitarianism) failed completely. Why do we run our IT shops as centrally planned economies? It’s because capitalism is messy. As architects, we need to accept the occasional useless program or project to allow the market to dictate where precious enterprise resources are best used. This goes against our grain but is vital for success in cloud.

Page 12: Why We Fail:  How an architect learned to stop worrying and love the cloud

Customer Centric IT

12

Traditional IT Customer Centric IT

Sets IT Standards Supports Business Requirements

Focus on Operations Excellence

Focus on Customer Satisfaction

Engineering is key skillset

Consulting is key skillset

Sets Policy Seeks Input

Focus on Large Projects Focus on Smaller Projects

Organized by Technology

Organized by Customer

Technology Focus Business Value Focus

Delivers most projects in house

Brokers external vendors as needed

In order to receive the full benefits of cloud, we must adopt a “Customer Centric IT” mandate. This means moving away from centrally planned standards driven organizations and towards services driven organizations that support the end business directly.

Page 13: Why We Fail:  How an architect learned to stop worrying and love the cloud

IT Portfolio Management

Strategic High Potential

Investments that are critical to achieving the future business strategy.

Investments which may be important in achieving

future success.

Investments which are essential to remain

competitive.

Investments which are valuable and deliver

improved performance, but are not critical to

success.

Key Operational Support

Co

ntr

ibu

tio

n t

o

bu

sin

ess

futu

re

Business dependence on current solution

One way to do this is to ALIGN the IT Portfolio to the business. This exercise, taken from the CranfieldSchool of Business, helps to ensure that IT is working on the right things and managing programs based on how they affect the business.

Page 14: Why We Fail:  How an architect learned to stop worrying and love the cloud

For More Information

14

This presentation was excerpted from my book, “Why We Fail” which is available on Amazon.com: http://bit.ly/AlexJauch

You can also listen to me giving this lecture at MMS here: http://bit.ly/WhyWeFailTalk

More about private cloud and enterprise architecture on my blog: http://bit.ly/ajauchblog