157
Delivery Strategies From idea to delivery: apps don’t deploy themselves Thursday, June 17, 2010

Delivery strategies: Apps don't deploy themselves

  • View
    5

  • Download
    0

Embed Size (px)

DESCRIPTION

E2 slides on application delivery and deployment.

Citation preview

Page 1: Delivery strategies: Apps don't deploy themselves

Delivery StrategiesFrom idea to delivery:apps don’t deploy themselves

Thursday, June 17, 2010

Page 2: Delivery strategies: Apps don't deploy themselves

So you have a new app.

Thursday, June 17, 2010

Page 3: Delivery strategies: Apps don't deploy themselves

Julien Smith, Bitnorth09Thursday, June 17, 2010

It’s going to make everything better.

Page 4: Delivery strategies: Apps don't deploy themselves

http

://w

ww

.flic

kr.c

om/p

hoto

s/pa

gedo

oley

/281

1157

950/

Thursday, June 17, 2010

You’ll collaborate!

Page 5: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/adamkr/4650637393/Thursday, June 17, 2010

You’ll be more productive, leaping over obstacles easily.

Page 6: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/joleson/1215644931/Thursday, June 17, 2010

The road ahead will be clear; you’ll make better decisions.

Page 7: Delivery strategies: Apps don't deploy themselves

Photo by Alan Cleaver from his Flicker Freestock set. Thanks, Alan!http://www.flickr.com/photos/alancleaver/2638883650/

Thursday, June 17, 2010

You’ll save money!

Page 8: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/ashevillein/2421648773/Thursday, June 17, 2010

Revenues will soar!

Page 9: Delivery strategies: Apps don't deploy themselves

Thursday, June 17, 2010

...so why are you so nervous?

Page 10: Delivery strategies: Apps don't deploy themselves

What we’ll cover

The democratization of IT

Understanding your constraints and goals

Possible delivery strategies

Thursday, June 17, 2010

Page 11: Delivery strategies: Apps don't deploy themselves

1950 1960 1970 1980 1990 2000 2010

Government

Military

Business

Hobbyist

Consumer Internet

Media

Consumer lifestyle

Thursday, June 17, 2010

Think about the evolution of computing.

Page 12: Delivery strategies: Apps don't deploy themselves

1970:The righthardware

1980:The right

application

1990:The right

integration

2000:The right adoption

Client-server architectures

Vendor dominance Web, SaaS, XML

Enterprise application adoption is

the new frontier

Where’s the risk?

Thursday, June 17, 2010

Page 13: Delivery strategies: Apps don't deploy themselves

Why this happenedDisruption and the democratization of IT

Thursday, June 17, 2010

Page 14: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/harshlight/3235469361Thursday, June 17, 2010

Once, IT was a monopoly.

Page 15: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/theclevelandkid24/4251408727/Thursday, June 17, 2010

Today, it’s a free market. The line of business has tremendous choice in what it owns, runs, and uses.

Page 16: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/hyku/2039448524/Thursday, June 17, 2010

The boardroom loves this: instead of managing machines, they manage services.

Page 17: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/ukanda/4455286483/Thursday, June 17, 2010

But enterprise IT doesn’t like it much, because it forces them to compete, and puts them side-by-side with organizations that spend their entire day doing detailed usage and billing.

Page 18: Delivery strategies: Apps don't deploy themselves

http://en.wikipedia.org/wiki/Adam_SmithThursday, June 17, 2010

It’s not all bad, though. There’s a lot to be learned from a transition from monopoly to a free market.

Page 19: Delivery strategies: Apps don't deploy themselves

Two reasons.

Thursday, June 17, 2010

There were a couple of reasons IT was a monopoly for so long.

Page 20: Delivery strategies: Apps don't deploy themselves

http

://w

ww

.flic

kr.c

om/p

hoto

s/br

ewbo

oks/

3319

7303

27/

(16MB)Thursday, June 17, 2010

First, the machines were expensive. That meant they were a scarce resource, and someone had to control what we could do with them.

Page 21: Delivery strategies: Apps don't deploy themselves

http

://w

ww

.flic

kr.c

om/p

hoto

s/ar

gonn

e/45

6339

4851

/

Thursday, June 17, 2010

Second, they were complicated. It took a very strange sect of experts to understand them. AVIDAC, Argonne's first digital computer, began operation in January 1953. It was built by the Physics Division for $250,000. Pictured is pioneer Argonne computer scientist Jean F. Hall.

AVIDAC stands for "Argonne Version of the Institute's Digital Automatic Computer" and was based on the IAS architecture developed by John von Neumann.

Page 22: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/ebeam/3586287989/Thursday, June 17, 2010

This was also a result of scarcity. When computers and humans interact, they need to meet each other halfway. But it takes a lot of computing power to make something that’s easy to use;

Page 23: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/ecastro/3053916892/Thursday, June 17, 2010

in the early days of computing, humans were cheap and machines weren’t

Page 24: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/binaryape/458758810/Thursday, June 17, 2010

So we used punched cards,

Page 25: Delivery strategies: Apps don't deploy themselves

http://50ans.imag.fr/images/galerie/Source/IBM-1130-1.jpgThursday, June 17, 2010

and switches,

Page 27: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/flem007_uk/4211743886/Thursday, June 17, 2010

Think about what a monopoly means.

Page 28: Delivery strategies: Apps don't deploy themselves

http

://w

ww

.flic

kr.c

om/p

hoto

s/ca

vem

an_9

2223

/353

1128

799/

Thursday, June 17, 2010

A monopoly was once awarded for a big project beyond the scope of any one organization, but needed for the public good.

Page 29: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/athomeinscottsdale/2850893998/Thursday, June 17, 2010

Sometimes, nobody wants the monopoly—like building the roads.

Page 30: Delivery strategies: Apps don't deploy themselves

Thursday, June 17, 2010

For the most part, governments have a monopoly on roadwork, because it’s something we need, but the benefits are hard to quantify or charge back for.

Page 31: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/leokoivulehto/2257818167/Thursday, June 17, 2010

(IT’s been handed many of these thankless tasks over the years, and the business has never complained.)

Page 32: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/crobj/4148482980/Thursday, June 17, 2010

The only time we can charge back for roads are when the resource is specific and billable: a toll highway, a bridge.

Page 33: Delivery strategies: Apps don't deploy themselves

http://en.wikipedia.org/wiki/File:Bell_System_hires_1900_logo.PNG

Thursday, June 17, 2010

Sometimes, we form a company with a monopoly, or allow one to operate, in order to build something or allow an inventor to recoup investment. This is how we got the telephone system, or railways.

Page 34: Delivery strategies: Apps don't deploy themselves

For much of its history, AT&T and its Bell System functioned as a legally sanctioned, regulated monopoly.

The US accepted this principle, initially in a 1913 agreement known as the Kingsbury Commitment.

Anti-trust suit filed in 1949 led in 1956 to a consent decree whereby AT&T agreed to restrict its activities to the regulated business of the national telephone system and government work.

Changes in telecommunications led to a U.S. government antitrust suit in 1974.

In 1982 when AT&T agreed to divest itself of the wholly owned Bell operating companies that provided local exchange service.

In 1984 Bell was dead. In its place was a new AT&T and seven regional Bell operating companies (collectively, the RBOCs.)

http://www.corp.att.com/history/history3.htmlThursday, June 17, 2010

When monopolies are created with a specific purpose, that’s good. But when they start to stagnate and restrict competition, we break them apart.

Page 35: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/ktylerconk/4096965228/Thursday, June 17, 2010

In fact, there’s a lot of antitrust regulation that prevents companies from controlling too much of something because they can stifle innovation and charge whatever they want. That’s one of the things the DOJ does.

Page 36: Delivery strategies: Apps don't deploy themselves

First: Monopoly good.

Thursday, June 17, 2010

In other words, early on monopolies are good because they let us undertake hugely beneficial, but largely unbillable, tasks.

Page 37: Delivery strategies: Apps don't deploy themselves

Then: Monopoly bad.

Thursday, June 17, 2010

Later, however, they’re bad because they reduce the level of creativity and experimentation.

Page 38: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/wikidave/2867257631/

Thursday, June 17, 2010

Today, computing is cheap. We can buy many times the compute power of the Apollo missions with a swipe of a credit card.

Page 39: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/mbrubeck/4460320021/

Thursday, June 17, 2010

It’s also not complicated. Everyone can use a computer. Because today, the computer is cheap and the human’s expensive we spend so much time on user interfaces, from GUIs to augmented reality to touchscreens to voice control to geopresence.

Page 40: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/raneko/4203965136/Thursday, June 17, 2010

What used to take a long time to procure, configure, and deploy is now a mouseclick.

Page 41: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/flem007_uk/4211743434/

Thursday, June 17, 2010

The lesson of monopolies is an important one. When a monopoly set out to build a railroad, it didn’t spend a lot of time asking potential travelers what they wanted.

Page 42: Delivery strategies: Apps don't deploy themselves

http://ww

w.flickr.com

/photos/dok1/4547024596/

Thursday, June 17, 2010

When you’re building something huge and expensive, you build what you want, and expect people to be grateful for it.

Page 43: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/mmbrown/3102707594/Thursday, June 17, 2010

But today’s IT user is driving IT requirements.

Page 44: Delivery strategies: Apps don't deploy themselves

Thursday, June 17, 2010

They can shop around—choosing SaaS, clouds, and internal IT according to their business requirements.

Page 45: Delivery strategies: Apps don't deploy themselves

http://www.codeproject.com/KB/miscctrl/ScriptStudio.aspx Wufoo.com

Thursday, June 17, 2010

They’re increasingly able to build the applications themselves, but expect IT to deliver smooth, fast platforms on which to experiment.

Page 46: Delivery strategies: Apps don't deploy themselves

HARDWARE

PLATFORMS

APPS

USERS

Thursday, June 17, 2010

It’s an inversion of the traditional IT “pyramid”, where the hardware dictates the platforms, which in turn dictates, the apps, which dictates what users can do.

Page 47: Delivery strategies: Apps don't deploy themselves

HARDWARE

PLATFORMS

APPS

USERS

Thursday, June 17, 2010

Today, what users want to do drives the apps they use, which drives the platforms and the hardware.

Page 48: Delivery strategies: Apps don't deploy themselves

Three really big changes.

Thursday, June 17, 2010

We’ve had big changes since that time. The first was client-server computing: the idea that not everything lived in a mainframe, and some things worked well on the desktop. Software like Visicalc—the first spreadsheet—were useful for businesses, even those who couldn’t afford a mainframe.

Page 49: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/scriptingnews/3471500626/Thursday, June 17, 2010

We’ve had big changes since that time. The first was client-server computing: the idea that not everything lived in a mainframe, and some things worked well on the desktop. Software like Visicalc—the first spreadsheet—were useful for businesses, even those who couldn’t afford a mainframe.

Page 50: Delivery strategies: Apps don't deploy themselves

http://en.wikipedia.org/wiki/File:NCSA_Mosaic.PNGThursday, June 17, 2010

A second big change was the Web. This browser-based model made computing accessible to the masses. As a result, it became part of society, and everyone knew how to work it. These days, you don’t have to teach a new hire how to use a web browser: they know what links do; what the back button is; and so on.

Page 51: Delivery strategies: Apps don't deploy themselves

!"#$%%&&&'()*+,'*-.%#!-/-0%#)1234566)*/%789:;7<=>%?Thursday, June 17, 2010

A third change is the move to mobility. This has been bigger overseas, where the mobile phone is the dominant way of accessing the Internet, but it’s still a shift to the always-connected, always-on lifestyles we lead today.

Page 52: Delivery strategies: Apps don't deploy themselves

Now here come clouds

Thursday, June 17, 2010

We’ve had big changes since that time. The first was client-server computing: the idea that not everything lived in a mainframe, and some things worked well on the desktop. Software like Visicalc—the first spreadsheet—were useful for businesses, even those who couldn’t afford a mainframe.

Page 53: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/jamesjordan/2751393381/Thursday, June 17, 2010

Cloud computing is an approach to computing that’s more flexible and lets organizations focus on their core business by insulating them from much of the underlying IT work.

Page 54: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/juniorvelo/3577399832/Thursday, June 17, 2010

At its most basic, it’s computing as a utility – pay for what you need, when you need it, rather than paying for it all up front.

Page 55: Delivery strategies: Apps don't deploy themselves

Picking a delivery strategyIdentifying your constraints

Thursday, June 17, 2010

Page 56: Delivery strategies: Apps don't deploy themselves

Square pegsDoes how your app will be used match the goals you have for it?

Thursday, June 17, 2010

Page 57: Delivery strategies: Apps don't deploy themselves

http://www.scottpargettphotography.com/images/photos/crowd.jpg

One to one One to many

http://exzanian.blogspot.com/2009/04/zuma-news-only-blip-on-world-radar.html

Thursday, June 17, 2010

First, think about the flow of communication and process. Is your intended use one-to-one, or one-to-many?

Page 58: Delivery strategies: Apps don't deploy themselves

!

Simple Detailed

Thursday, June 17, 2010

Then think about message complexity. Are you sending quick, brief information; or very detailed data?

Page 59: Delivery strategies: Apps don't deploy themselves

Detailed

Simple

One to one One to many

IM

Email

Twitter

Blogcomment

Linkedinprofilechange

IRC

Facebookstatusupdate

Googlegroup

Privatewiki

Blogpost

Forumcomment

Forumpost

Article

Com

plex

ity

Community

Thursday, June 17, 2010

Form follows function: The dimensions of enterprise software. The reality is that every kind of interaction is unique. Some are private, one-to-one; others are open to everyone. Some are brief snippets; others, detailed prose. Different apps are better for different kinds of interaction; others won’t feel natural.

Page 60: Delivery strategies: Apps don't deploy themselves

Operational constraintsWhat are the rules and limitations to consider?

Thursday, June 17, 2010

Page 61: Delivery strategies: Apps don't deploy themselves

Is performance acceptable?

Thursday, June 17, 2010

Page 62: Delivery strategies: Apps don't deploy themselves

(1981) A. J. Thadhani, IBM Systems Journal, Volume 20, number 4

Figure 3 Interactive user productivity versus computer response time for human-intensive

interactions for system A

E 600 3

-

T

7

w

z

E 500 -

U

E w

E - >

> - -

400 - 3 n

F2

300 -

200 -

100 -

0 -

0

-" INTERACTIVE USER PRODUCTIVITY (IUP)

- HUMAN-INTENSIVE COMPONENT OF IUP

A MEASURED DATA (HUMAN-INTENSIVE " COMPONENT)

0

0

0

0

I 1 I I I 1 2 3 4 5

COMPUTER RESPONSE TIME (SI

The human-intensive component of IUP is computed by using completed period 1 interactions, instead of all TSO interactions in Equation 1.

When the number of logged-on users on the system is small, it is possible for a few users to have an inordinately large effect on the aggregate user work, and hence bias the results. To minimize bias, all data with fewer than twenty-five logged-on users were excluded from the analysis. Furthermore, to minimize the effect of changes in the aggregate user work at different times of the month, the data collected were separated into groups of six to eight consecutive days and analyzed separately. One repre-

sentative sample is used for IUP for each system, with least squares fitted third-order negative exponent polynomial for IUP.

Results and their interpretation

The data summarized in Figures 3 and 4 show that interactive user productivity and the computer response time (CRT) for

412 THADHANI IBM SYST J 0 VOL 20 0 NO 4 0 1981

Thursday, June 17, 2010

There’s a study from IBM in 1981 that shows strong evidence of the relationship between performance and productivity. As systems get faster, users get EXPONENTIALLY more productive.

Page 63: Delivery strategies: Apps don't deploy themselves

http

://w

ww

.flic

kr.c

om/p

hoto

s/bi

llsel

ak/3

6669

2332

/

Thursday, June 17, 2010

How fast can you afford? Sure, instantaneous is good, but it also costs an infinite amount.

Page 64: Delivery strategies: Apps don't deploy themselves

Customization

Thursday, June 17, 2010

How many people want to customize their word processor?

Page 65: Delivery strategies: Apps don't deploy themselves

http://www.codeproject.com/KB/miscctrl/ScriptStudio.aspx Wufoo.com

Thursday, June 17, 2010

Remember those drag-and-drop, parametric screens?

Page 66: Delivery strategies: Apps don't deploy themselves

Thursday, June 17, 2010

Many SaaS providers are adding customization and scripting that blurs the lines of what’s a cloud, and what’s an app, and what’s a programming language. Now that you can write code for Google Apps -- as in this example of a script that sends custom driving directions to everyone in a spreadsheet -- the distinction is less and less clear.

Page 67: Delivery strategies: Apps don't deploy themselves

The turnkey/tuning tradeoff.

Thursday, June 17, 2010

Page 68: Delivery strategies: Apps don't deploy themselves

Standardized

Tailored

Slow, inefficient

Fast/lean, witheconomies of scale

Easy

Easy

Impossible

Sloppy

Thursday, June 17, 2010

Unfortunately, there’s a tradeoff here -- everyone wants fast, cheap, and customized. You can only have two. The more tailored your IT systems are, the more you’ll be paying for them and the slower they’ll be. At the same time, if you use the same applications and processes as everyone else you may sacrifice important differentiators.

Page 69: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/andrewparnell/2738598951/Thursday, June 17, 2010

An increasingly important criteria is the ability to connect existing systems to new ones. Whether this is legacy applications (for authentication, data exchange, or single sign-on); or to third-party customers and partners, the ability to link your systems to others is a huge deal.

Page 70: Delivery strategies: Apps don't deploy themselves

Thursday, June 17, 2010

This is one of the reasons a thriving ecosystem around a platform is so important -- because it’s an indicator of ability to develop to the platform, as well as a starting point for integration and extension.

Page 71: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/oobrien/7597395/Thursday, June 17, 2010

Then there’s compliance and security. This may include geographic and legislative issues (where you can put your data) as well as auditing and logging (some industries require physical collection by a separate system.)

Page 72: Delivery strategies: Apps don't deploy themselves

Security is a...

http://www.thewhir.com/web-hosting-news/102309_IT_Firms_Skeptical_About_Cloud_PEER_1_Study

Reason to avoid clouds23%

No opinion34%

Reason to move to clouds43%

Thursday, June 17, 2010

This isn’t just about avoiding on-demand systems. The odds are good that many cloud providers are better at security than you are.

Page 73: Delivery strategies: Apps don't deploy themselves

Budget & operating constraintsWhat can you afford to take on?

Thursday, June 17, 2010

Page 74: Delivery strategies: Apps don't deploy themselves

Airfare

DNS

Cloud

Publictransit

Importantresearch

Hotel

Thursday, June 17, 2010

Affordability

Page 75: Delivery strategies: Apps don't deploy themselves

Time (years)

Mon

ey s

pent Point at which

it’s cheaper to buy than rent

Thursday, June 17, 2010

The economics of renting versus buying apply here, too, since the investment is approaching zero. The traditional way of looking at this is to compare an upfront investment to the rental model of a lesser investment (integration, training) and a pay-as-you-go cost.

Page 76: Delivery strategies: Apps don't deploy themselves

Time (years)

Mon

ey s

pent

Cheaper to rent for longer

Thursday, June 17, 2010

Several things have changed in recent years in this respect. First, the upfront investment of a pay-as-you-go model has dropped: everyone knows how to use a browser; everyone can access things remotely; vendors have trial models; and so on. So it takes longer to get to the point where it’s cheaper to run your own thing.

Page 77: Delivery strategies: Apps don't deploy themselves

Time (years)

Mon

ey s

pent

Unforeseen costs of owning

Thursday, June 17, 2010

There’s also the impact of owning things. Often, IT is a distraction; we make decisions based on existing investments, which means we don’t change things when we can, which means we become less agile.

Page 78: Delivery strategies: Apps don't deploy themselves

Time (years)

Mon

ey s

pent

Efficiencies from economies of

scale passed on to customers

Thursday, June 17, 2010

There’s also the impact of owning things. Often, IT is a distraction; we make decisions based on existing investments, which means we don’t change things when we can, which means we become less agile.

Page 79: Delivery strategies: Apps don't deploy themselves

Time (years)

Mon

ey s

pent

5 year planning horizon

6 months

Payoff time

Thursday, June 17, 2010

But even if you ignore all of these, here’s why pay-as-you-go wins more and more often: Your time horizon isn’t what it used to be. By the time you’ve paid off your in-house investment, your business will have changed in order to adapt, and you’ll be after something else.

Page 80: Delivery strategies: Apps don't deploy themselves

Ease of adoptionHow readily will your users take to it?

Thursday, June 17, 2010

Page 81: Delivery strategies: Apps don't deploy themselves

Thursday, June 17, 2010

Existing standards: why do you know what to do here?

Page 82: Delivery strategies: Apps don't deploy themselves

Thursday, June 17, 2010

Learning curve is okay; in fact, it’s recommended. Think what it would be like to have to use a wizard every time you wanted to do something.

Page 83: Delivery strategies: Apps don't deploy themselves

Thursday, June 17, 2010

Consider Excel: most beginners can grasp it easily; but it’s designed to allow experts to be more productive. This is essential when evaluating how readily your user base will adopt something -- not just on day one, but on day fifty, when they’re expected to be fast and error-free.

Page 84: Delivery strategies: Apps don't deploy themselves

http

://w

ww

.flic

kr.c

om/p

hoto

s/fa

rhan

nasi

r/45

7750

8824

/

Thursday, June 17, 2010

Also consider the impact of mobility, and new platforms. Will your users be able to adopt the application in all the places they work?

Page 85: Delivery strategies: Apps don't deploy themselves

App/usage fit: Does app function match planned use?

Is the flow of information the right degree of open?Do users work at the right degree of information detail?

Operational constraints

Will it perform fast enough to make users productive?Can I customize it to my business without making it suck?Can I connect it to myself and my partners?Does it comply with legal, privacy, security requirements?

Budget & operating constraints

How does it embody new payment models (freemium, etc.)?Do I understand the ROI & TCO of my chosen approach?

Ease of adoption

Does it use existing standards & conventions my users know?Can first-timers use it, but experts be fast & efficient?Will it work in mobile, disconnected, touch UI, etc.?

Thursday, June 17, 2010

Here’s a quick recap of the criteria we just saw.

Page 86: Delivery strategies: Apps don't deploy themselves

Possible delivery strategiesPlatforms & business models to choose from.

Thursday, June 17, 2010

Okay, now let’s look at some of the platforms and business models you can use for this.

Page 87: Delivery strategies: Apps don't deploy themselves

Dedicatedhardware

On-premiseprivate clouds

Virtualprivate clouds

Third-partypublic clouds

Thursday, June 17, 2010

There’s a spectrum of platforms out there on which you can run an application.

Page 88: Delivery strategies: Apps don't deploy themselves

Bare metal(this is your computer)

Thursday, June 17, 2010

First, there’s bare metal.

Page 89: Delivery strategies: Apps don't deploy themselves

http://techyshit.com/15-computer-ads-from-the-past-1950-1980/

Thursday, June 17, 2010

It’s pretty cheap. The vast majority of costs -- sometimes as much as five times the cost of the hardware -- come from operating it, powering it, cooling it, and so on.

Page 90: Delivery strategies: Apps don't deploy themselves

Virtual machinesStill yours...

Thursday, June 17, 2010

Then there’s virtualization.

Page 91: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/mynameisharsha/4092086880/Thursday, June 17, 2010

The  step-­‐func7on  nature  of  bare-­‐metal  dedicated  machines  doesn’t  distribute  workload  very  efficiently.

Page 92: Delivery strategies: Apps don't deploy themselves

http

://w

ww

.flic

kr.c

om/p

hoto

s/h4

ck/2

4135

6210

8/

Thursday, June 17, 2010

Virtualization lets us put many workloads on a single machine

Page 93: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/stawarz/3538910787/Thursday, June 17, 2010

Once  workloads  are  virtualized,  several  things  happen.  First,  they’re  portable

Page 94: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/swimparallel/3391592144/Thursday, June 17, 2010

Second,  they’re  ephemeral.  That  is,  they’re  short-­‐lived:  Once  people  realize  that  they  don’t  have  to  hoard  machines,  they  spin  them  up  and  down  a  lot  more.

Page 95: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/genewolf/147722350Thursday, June 17, 2010Which  inevitably  leads  to  automa3on  and  scrip3ng:  We  need  to  spin  up  and  down  machines,  and  move  them  from  place  to  place.  This  is  hard,  error-­‐prone  work  for  humans,  but  perfect  for  automa3on  now  that  rack-­‐and-­‐stack  has  been  replaced  by  point-­‐and-­‐click

Page 96: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/pinkmoose/3278324276/Thursday, June 17, 2010

Automa7on,  once  in  place,  can  have  a  front  end  put  on  it.  That  leads  to  self  service.

Page 97: Delivery strategies: Apps don't deploy themselves

Virtualization divorces the app from the machine.

Physicalmachine

Physicalmachine

Physicalmachine

Physicalmachine

Physicalmachine

Physicalmachine

Virtual machine

One on many

Physical machine

Virtual machine

Virtual machine

Virtual machine

Virtual machine

Virtual machine

Virtual machine

Many on one(or)

Thursday, June 17, 2010

Okay, so these things mean we have applications that run “virtually” – that is, they’re divorced from the underlying hardware. One machine can do ten things; ten machines can do one thing.

Page 98: Delivery strategies: Apps don't deploy themselves

“Cloudy”  tech.Thursday, June 17, 2010

These  are  the  founda7ons  on  which  new  IT  is  being  built.  Taken  together,  they’re  a  big  part  of  the  movement  towards  cloud  compu7ng,  whether  that’s  in  house  or  on-­‐demand.  If  you  do  all  these  things,  you’re  running  what  many  people  call  a  “private  cloud”

Page 99: Delivery strategies: Apps don't deploy themselves

Virtual private clouds(feels like yours)

Thursday, June 17, 2010

If you like the virtualization, but don’t like having to carry a screwdriver around, virtual private clouds may be right for you.

Page 100: Delivery strategies: Apps don't deploy themselves

http://nature.wallpaperme.com/Nature-Historical-Buildings/Fairy+Tale+Fantasy_+Neuschwanstein+Castle_+Bavaria_+Germany.jpg.html?g2_imageViewsIndex=1

Thursday, June 17, 2010

In this approach, you have a machine that feels like it’s your own -- complete with a private IP address and so on. If you want to connect it to the Internet, you do so yourself; it’s just like virtual infrastructure, but someone else is running it.

Page 101: Delivery strategies: Apps don't deploy themselves

Infrastructure as a ServiceAmazon EC2, Rackspace Cloud, Terremark, Gogrid, Joyent (and nearly every private cloud built on Zenserver or VMWare.)

Thursday, June 17, 2010

When IT people talk about cloud computing, they usually mean something called IaaS.

Page 102: Delivery strategies: Apps don't deploy themselves

http://aws.amazon.com/ec2/pricing/Thursday, June 17, 2010

These are really just virtual machines I can use for just an hour, already connected to the Internet. Here’s Amazon’s “menu” of machines.

Page 103: Delivery strategies: Apps don't deploy themselves

•60 seconds per page

•200 machine instances

•1,407 hours of virtual machine time

•Searchable database available 26 hours later

•$144.62 total cost

Desktop EC2

Pages 17,481 17,481

Minutes/page 1 1

# of machines 1 200

Total minutes 17,481

Total hours 291.4 26.0

Total days 12.1 1.1

Thursday, June 17, 2010

A great example of these clouds in action is what the Washington Post did with Hillarly Clinton’s diaries during her campaign. They needed to get all 17,481 pages of Hillary Clinton’s White House schedule scanned and searchable quickly. Using 200 machines, the Post was able to get the data to reporters in only 26 hours. In fact, the experiment is even more compelling: Desktop OCR took about 30 minutes per page to properly scan, read, resize, and format each page – which means that it would have taken nearly a year, and cost $123 in power, to do the work on a single machine.

Page 104: Delivery strategies: Apps don't deploy themselves

Web server

Machine instance

MachineImage

Thursday, June 17, 2010

In an IaaS model, you’re getting computers as a utility. The unit of the transaction is a virtual machine. It’s still up to you to install an operating system, and software, or at least to choose it from a list. You don’t really have a machine -- you have an image of one, and when you stop the machine, it vanishes.

Page 105: Delivery strategies: Apps don't deploy themselves

App Server

Machine instance

Web server

Machine instance

DBserver

Machine instance

Storage

MachineImage

MachineImage

MachineImage

Thursday, June 17, 2010

Most applications consist of several machines -- web, app, and database, for example. Each is created from an image, and some, like databases, may use other services from the cloud to store and retrieve data from a disk

Page 106: Delivery strategies: Apps don't deploy themselves

App Server

Machine instance

Web server

Machine instance

DBserver

Machine instance

StorageDB

server

Biggermachineinstance

Thursday, June 17, 2010

If you run out of capacity, you can upgrade to a bigger machine (which is called “scaling vertically.”)

Page 107: Delivery strategies: Apps don't deploy themselves

App Server

Machine instance

Web server

Machine instance

DBserver

Machine instance

Storage

App Server

Machine instance

Web server

Machine instance

DBserver

Machine instance

LoadbalancerMachine instance

Thursday, June 17, 2010

Or you can create several machines at each tier, and use a load balancer to share traffic between them. These kinds of scalable, redundant architectures are common -- nay, recommended -- in a cloud computing world where everything is uncertain.

Page 108: Delivery strategies: Apps don't deploy themselves

Platform as a ServiceGoogle App Engine, Salesforce Force.com, Rackspace Cloud Sites, Joyent Smart Platform, (and nearly every enterprise mainframe.)

Thursday, June 17, 2010

The second kind of cloud is called Platform as a Service. In this model, you don’t think about the individual machines—instead, you just copy your code to a cloud, and run it. You never see the machines. In a PaaS cloud, things are very different.

Page 109: Delivery strategies: Apps don't deploy themselves

Processing platformData API

Storage

Yourcode

Others’code

Others’code

Others’code

Others’code

Others’code

Auth API

Userdatabase

Image API

Image functions

Blob API

Big objects

...

Governor Console Schedule

Shared components

Thursday, June 17, 2010

- You write your code; often it needs some customization.- That code runs on a share processing platform- Along with other people’s code- The code calls certain functions to do things like authenticate a user, handle a payment, store an object, or move something to a CDN- To keep everything running smoothly (and bill you) the platform has a scheduler (figuring out what to do next) and a governor (ensuring one program doesn’t use up all the resources) as well as a console.

Page 110: Delivery strategies: Apps don't deploy themselves

http://code.google.com/appengine/articles/load_test_screenshot.jpgThursday, June 17, 2010

Here’s a shot of some code running in Google App Engine. I only know that I’m paying by CPU-hour, or for units like bandwidth, email, or storage. This could be one machine whose CPU was used 8%, or a hundred, or a thousand. I don’t know.

Page 111: Delivery strategies: Apps don't deploy themselves

http://code.google.com/appengine/articles/logs_admin.pngThursday, June 17, 2010

I can see the logs for my application. But these aren’t for a single machine -- they’re for the application itself, everywhere.

Page 112: Delivery strategies: Apps don't deploy themselves

http://googleappengine.blogspot.com/2010/03/easy-performance-profiling-with.htmlThursday, June 17, 2010

I can even find out what parts of my code are consuming the most CPU, across all machines.

Page 113: Delivery strategies: Apps don't deploy themselves

Thursday, June 17, 2010

And even their latency when served to people.

Page 114: Delivery strategies: Apps don't deploy themselves

http://ww

w.com

puterhok.nl/JSP

Wiki/attach/G

oogleAppE

ngine/GA

EQ

uota.png

Thursday, June 17, 2010

It’s a true, pure utility because you pay for what you use.

Page 115: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/olitaillon/3354855989/Thursday, June 17, 2010

This is a very different model from IaaS. On the one hand, it’s more liberating, because you don’t have to worry about managing the machines. On the other hand, it’s more restrictive, because you can only do what the PaaS lets you.

Page 116: Delivery strategies: Apps don't deploy themselves

IaaS and PaaS differences

IaaS

Any operating system you want

Limited by capacity of virtual machine

Scale by adding more machines

Many storage options (file system, object, key-value)

PaaS

Use only selected languages and built-in APIs

Limited by governors to avoid overloading

Scaling is automatic

Use built-in storage (Bigtable, etc.)

Thursday, June 17, 2010

In the case of Google’s App Engine, you have to use their functions and store things in the way they want you to. You get great performance from doing so, but it probably means rewriting your code a bit.

Page 117: Delivery strategies: Apps don't deploy themselves

Quota LimitApps per developer 10Time per request 30sBlobstore (total file size) 1GBMaximum HTTP response size 10MBDatastore item size 1MBApplication code size 150MB

Emails per day 1,500Bandwidth in per day 1 GBBandwidth out per day 1GBCPU time per day 6.5hHTTP requests per day 1,300,000Datastore API calls per day 10,000,000URLFetch API calls per day 657,084

Governor(usage cap)

Daily cap(free quota)

http://en.wikipedia.org/wiki/Google_App_EngineThursday, June 17, 2010

PaaS platforms impose usage caps and billing tiers. Here’s Google App Engine’s set of quotas and free caps.

Page 118: Delivery strategies: Apps don't deploy themselves

http://wiki.developerforce.com/index.php/Apex_Code:_The_World%27s_First_On-Demand_Programming_LanguageThursday, June 17, 2010

In the case of Salesforce’s Force.com, you have to use an entirely new programming language, called Apex.

Page 119: Delivery strategies: Apps don't deploy themselves

Software as a ServiceSalesforce.com, Google Apps, Microsoft Office Live, pretty much any ISV still around today.

Thursday, June 17, 2010

The third kind of “cloud” app is really just a new software delivery model; I hesitate to call them clouds at all, actually. It’s SaaS. And it’s what most people outside of IT think of as “cloud computing.”

Page 120: Delivery strategies: Apps don't deploy themselves

Thursday, June 17, 2010

The third kind of cloud is called Software as a Service, or SaaS. Some people argue that this isn’t a cloud at all, just a new way of delivering software. But it’s also what the masses—the non-technologists—think cloud computing means. The problem is that SaaS is pretty much synonymous with “dynamic website” or “the Internet” these days. Nevertheless, if an ISV is shipping software on discs still, their days are numbered.

Page 121: Delivery strategies: Apps don't deploy themselves

How you pay for itLots of business models

Thursday, June 17, 2010

Page 122: Delivery strategies: Apps don't deploy themselves

DIYYou can always write your own stuff.

Thursday, June 17, 2010

Page 123: Delivery strategies: Apps don't deploy themselves

Open sourceStanding on the shoulders of giants

Thursday, June 17, 2010

Page 124: Delivery strategies: Apps don't deploy themselves

Gith

ub a

naly

sis

by F

ranc

k C

uny:

htt

p://

ww

w.fl

ickr

.com

/pho

tos/

franc

k_/s

ets/

7215

7623

4478

5740

5/

Thursday, June 17, 2010

Github is a great example of how social coding has transformed and revitalized the open source world, particularly for high-level languages like Rails and Python.

Page 125: Delivery strategies: Apps don't deploy themselves

Thursday, June 17, 2010

One last thought about building your own, rather than building it as part of a bigger platform: Adoption is what matters. There’s a build-your-own dilemma: If you create a new environment, you need to change users’ patterns.

Page 127: Delivery strategies: Apps don't deploy themselves

FreemiumAnd other sad, bad portmanteaux

Thursday, June 17, 2010

Page 128: Delivery strategies: Apps don't deploy themselves

Collaborativebusinessmodel

Transactionalbusiness

modelUser creates content

Content remains private

Paid

Content becomes part of template

library

Free

Eventualconversion

Engagement, SEO ranking

Revenues

Thursday, June 17, 2010

New freemium models for SaaS blend transactional and collaborative revenue approaches. In this model, “free” users help build the corpus of templates, contributing to SEO ranking and the richness of the offering; while paying users can keep their work private.

Page 129: Delivery strategies: Apps don't deploy themselves

Composed applicationStitching together loosely coupled pieces

Thursday, June 17, 2010

Page 130: Delivery strategies: Apps don't deploy themselves

Thursday, June 17, 2010

Page 131: Delivery strategies: Apps don't deploy themselves

Thursday, June 17, 2010

Page 132: Delivery strategies: Apps don't deploy themselves

SaaSPay as you go.

Thursday, June 17, 2010

Page 133: Delivery strategies: Apps don't deploy themselves

Thursday, June 17, 2010

Whether it’s PaaS, SaaS, or IaaS, the model is the same: Sell IT on demand, rather than as software or machines.

Page 134: Delivery strategies: Apps don't deploy themselves

AdoptionThe real risk when the app is a utility

Thursday, June 17, 2010

Page 135: Delivery strategies: Apps don't deploy themselves

Thursday, June 17, 2010

The whole reason you deploy apps is so that you can focus on the things you do best: whatever adds the most value to your business.

Page 136: Delivery strategies: Apps don't deploy themselves

Thursday, June 17, 2010

You also deploy apps to handle processes you didn’t want to do yourself anyway.

Page 137: Delivery strategies: Apps don't deploy themselves

“What information consumes is rather

obvious: it consumes the attention of its

recipients. Hence, a wealth of information

creates a poverty of attention and a need

to allocate that attention efficiently among

the overabundance of information sources

that might consume it.”

Herbert Simon

Thursday, June 17, 2010

The problem isn’t delivery: we have plenty of options for that. It’s adoption.

Page 138: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/gideon/6582069/Thursday, June 17, 2010

But your users might well not adopt the app despite your best efforts, because they don’t like it, or don’t notice it, or aren’t adopting it in the way you’d hoped.

Page 139: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/roebot/4271975019/Thursday, June 17, 2010

At the same time, you’re seeing what tools and processes are getting adopted -- what’s working? what’s popular? -- and doubling down on those things.

Page 140: Delivery strategies: Apps don't deploy themselves

How do you fix this?

Thursday, June 17, 2010

Page 141: Delivery strategies: Apps don't deploy themselves

Analytics.

Thursday, June 17, 2010

Page 142: Delivery strategies: Apps don't deploy themselves

NEWVISITORS

GROWTH

BOUNCERATE

LOSS

CONVERSIONRATE

GOALVALUE

xTIMEON

SITE

PAGESPERVISIT

NUMBEROF VISITS

SEARCHES

TWEETS

MENTIONS

ADS SEEN

ATTENTION ENGAGEMENT CONVERSION

Thursday, June 17, 2010

Here’s the simplest possible analytics model.

Page 143: Delivery strategies: Apps don't deploy themselves

For transactional sites

Can people buy things?

Thursday, June 17, 2010

Remember the four kinds of sites? You need to analyze and optimize the app you’re delivering in the same way.

A site that wants visitors to complete a transaction—normally a purchase—is transactional. There’s an “ideal path” through the site that its designers intended, resulting in a goal or outcome of some kind. The goal isn’t always a purchase; it can also be enrollment (signing up for email) or lead generation (asking salespeople to contact them), and can happen either online or off. For e-commerce, that’s whatever your transaction consists of.

Page 144: Delivery strategies: Apps don't deploy themselves

For media sites

Are ads loading quickly and successfully clicked through?

Is content loading fast enough for visitors?

Thursday, June 17, 2010

These sites offer content that attracts and retains an audience. They make money from that content through sponsorship, advertising, or affiliate referrals. Search engines, Adwords-backed sites, newspapers, and well-known bloggers are media properties. For media sites, that’s making money from ads.

Page 145: Delivery strategies: Apps don't deploy themselves

For collaboration sites

Can visitors contribute (posting content, voting?)

Is bad content being mitigated (trolling, spam)?

Thursday, June 17, 2010

On these sites, visitors generate the content themselves. Wikis, news aggregators, user groups, classified ad listings, and other web properties in which the value of the site is largely derived from things created by others are all collaborative.

For collaboration, that’s creating and curating content.

Page 146: Delivery strategies: Apps don't deploy themselves

For SaaS sites

Are your end users productive?

Are they making fewer mistakes?

Is the site working during customers’ business hours?

Thursday, June 17, 2010

These sites are hosted versions of software someone might buy. SaaS subscribers expect reliability and may pay a monthly per-seat fee for employees to use the service. Revenues come from subscriptions, and a single subscriber may have many user accounts. On some SaaS sites, users are logged in for hours every day.

For SaaS sites, that’s productivity and an error-free experience.

Page 147: Delivery strategies: Apps don't deploy themselves

Helpdeskescalation

SLAviolation

Renewal, upsell,reference

Performance

End user (employee)

SaaS site

Churn $

Refund $

6

2

Enterprise subscriber

1

5

3

4

Good Bad

Usability

Good Bad

Productivity

Good Bad

7

Supportcosts $

Impact on site

NegativePositive $$

$

$

Thursday, June 17, 2010

The closest your app will be to one of the four “public” websites is a SaaS site. Here’s the business model for a SaaS site.

Page 148: Delivery strategies: Apps don't deploy themselves

(Insert your app here)

Are they adopting the app at the rate you expect?

Are they abandoning the old ways?

What are they using most or neglecting?

How productive are they?

Where are they making mistakes?

?

Thursday, June 17, 2010

What does your adoption and usage map look like?

Page 149: Delivery strategies: Apps don't deploy themselves

The cycle of optimization

Metrics & strategy

Collection

Reporting

Institutionalizing the results

Link to KPI/ROI

Optimization & change

Thursday, June 17, 2010

Optimization involves a constant cycle of collection, reporting, communicating and sharing the data, tying it to business processes, changing the system, and repeating.

Page 150: Delivery strategies: Apps don't deploy themselves

The good news:you can experiment easily

We stop worrying about ROI when I is zero.

Thursday, June 17, 2010

Page 151: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/steven_wong/2440355239/Thursday, June 17, 2010

They’re not dictating and restricting; rather, they’re regulating usage to ensure a good balance of risk and experimentation

Page 152: Delivery strategies: Apps don't deploy themselves

Beyond adoption: outcomes

Deployment Awareness AdoptionBusinessoutcomes

Thursday, June 17, 2010

Once you’ve got adoption, you’re not done: the same tools will let you measure the outcomes:- More productivity- Abandonment of old/bad methods- More leads- Lower cost- Fewer errors- Etc.

Page 153: Delivery strategies: Apps don't deploy themselves

One final thoughtPaving the cowpaths

Thursday, June 17, 2010

Page 154: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/jelles/2902422030/Thursday, June 17, 2010

One approach is to “pave the cowpaths.”

Page 155: Delivery strategies: Apps don't deploy themselves

http://www.flickr.com/photos/32314864@N02/3253051215/Thursday, June 17, 2010

This is an old civil engineering trick: Watch where people walk, then put paths there.

Page 156: Delivery strategies: Apps don't deploy themselves

The next 3 daysThe inside-out organization: Connecting to customers and markets

Mobile Platforms and Enterprise Agility

The Politics of Delivery: Compliance and Governance

Platform Options in the New IT Landscape

Social Behavior, Usage Patterns, and Adoption

Can IT Lead the Social Business Strategy Formulation Process?

Delivery Strategies: The Road Ahead

Tues

day

Wed

nesd

ayTh

ursd

ay

Thursday, June 17, 2010

Page 157: Delivery strategies: Apps don't deploy themselves

Thanks!@[email protected]

Thursday, June 17, 2010