Delivery Strategies: From Idea to Deployment

Delivery Strategies
From idea to delivery:
apps don’t deploy themselves

Thursday, June 17, 2010

So you have a new app.


Julien Smith, Bitnorth09

It’s going to make everything better.


You’ll collaborate!

http://www.ﬂickr.com/photos/pagedooley/2811157950/

http://www.ﬂickr.com/photos/adamkr/4650637393/

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

http://www.ﬂickr.com/photos/joleson/1215644931/

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

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

You’ll save money!

http://www.ﬂickr.com/photos/ashevillein/2421648773/

Revenues will soar!


...so why are you so
nervous?

What we’ll cover

The democratization of IT
Understanding your constraints and goals
Possible delivery strategies


1950 1960 1970 1980 1990 2000 2010

Government

Military

Business

Hobbyist

Consumer Internet

Consumer lifestyle

Media


Think about the evolution of computing.

Where’s the risk?
1970: 1980: 1990: 2000:
The right The right The right The right
hardware application integration adoption

Client-server Vendor
Web, SaaS, XML
architectures dominance

Enterprise
application adoption is
the new frontier


Why this happened
Disruption and the democratization of IT


http://www.ﬂickr.com/photos/harshlight/3235469361
Once, IT was a monopoly.

http://www.ﬂickr.com/photos/theclevelandkid24/4251408727/
Today, it’s a free market. The line of business has tremendous choice in what it owns, runs, and uses.

http://www.ﬂickr.com/photos/hyku/2039448524/
The boardroom loves this: instead of managing machines, they manage services.

http://www.ﬂickr.com/photos/ukanda/4455286483/
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.

http://en.wikipedia.org/wiki/Adam_Smith
It’s not all bad, though. There’s a lot to be learned from a transition from monopoly to a free market.

Two reasons.

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

http://www.ﬂickr.com/photos/brewbooks/3319730327/
(16MB)
First, the machines were expensive. That meant they were a scarce resource, and someone had to control what we could do with
them.

http://www.ﬂickr.com/photos/argonne/4563394851/
Second, they were complicated. It took a very strange sect of experts to understand them. AVIDAC, Argonne's ﬁrst 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.

http://www.ﬂickr.com/photos/ebeam/3586287989/
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;

http://www.ﬂickr.com/photos/ecastro/3053916892/
in the early days of computing, humans were cheap and machines weren’t

http://www.ﬂickr.com/photos/binaryape/458758810/
So we used punched cards,

http://50ans.imag.fr/images/galerie/Source/IBM-1130-1.jpg
and switches,

http://honeynet.onofri.org/scans/scan22/sol/submission/reverse.jpg
and esoteric programming languages like assembler.

http://www.ﬂickr.com/photos/ﬂem007_uk/4211743886/
Think about what a monopoly means.

http://www.ﬂickr.com/photos/caveman_92223/3531128799/
A monopoly was once awarded for a big project beyond the scope of any one organization, but needed for the public good.

http://www.ﬂickr.com/photos/athomeinscottsdale/2850893998/
Sometimes, nobody wants the monopoly—like building the roads.

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

http://www.ﬂickr.com/photos/leokoivulehto/2257818167/
(IT’s been handed many of these thankless tasks over the years, and the business has never complained.)

http://www.ﬂickr.com/photos/crobj/4148482980/
The only time we can charge back for roads are when the resource is speciﬁc and billable: a toll highway, a bridge.

http://en.wikipedia.org/wiki/File:Bell_System_hires_1900_logo.PNG
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.

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 ﬁled 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.html
When monopolies are created with a speciﬁc purpose, that’s good. But when they start to stagnate and restrict competition, we
break them apart.

http://www.ﬂickr.com/photos/ktylerconk/4096965228/
In fact, there’s a lot of antitrust regulation that prevents companies from controlling too much of something because they can
stiﬂe innovation and charge whatever they want. That’s one of the things the DOJ does.

First: Monopoly good.

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

Then: Monopoly bad.

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

http://www.ﬂickr.com/photos/wikidave/2867257631/

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

http://www.ﬂickr.com/photos/mbrubeck/4460320021/

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.

http://www.ﬂickr.com/photos/raneko/4203965136/
What used to take a long time to procure, conﬁgure, and deploy is now a mouseclick.

http://www.ﬂickr.com/photos/ﬂem007_uk/4211743434/

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.

http://www.ﬂickr.com/photos/dok1/4547024596/
When you’re building something huge and expensive, you build what you want, and expect people to be grateful for it.

http://www.ﬂickr.com/photos/mmbrown/3102707594/
But today’s IT user is driving IT requirements.

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

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

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

USERS

APPS

PLATFORMS

HARDWARE

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.

USERS

APPS

PLATFORMS

HARDWARE

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

Three really big changes.


We’ve had big changes since that time. The ﬁrst 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 ﬁrst spreadsheet—were useful for businesses, even those who couldn’t
afford a mainframe.

http://www.ﬂickr.com/photos/scriptingnews/3471500626/

afford a mainframe.

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

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.

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

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.

Now here come clouds


afford a mainframe.

http://www.ﬂickr.com/photos/jamesjordan/2751393381/

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

http://www.ﬂickr.com/photos/juniorvelo/3577399832/

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.

Picking a delivery strategy
Identifying your constraints


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


One to one One to many

http://exzanian.blogspot.com/2009/04/zuma-news-only-blip-on-world-radar.html
http://www.scottpargettphotography.com/images/photos/crowd.jpg

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

!

Simple Detailed


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

Community
Detailed Email Article
Blog
Private post
wiki

Forum Google
comment group
Forum
Linkedin post
IRC proﬁle
change
Blog
comment

Complexity
Facebook
status
update
IM Twitter
Simple
One to one One to many

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.

Operational constraints
What are the rules and limitations to consider?


Is performance acceptable?


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

E 600
-
3

T -" INTERACTIVE USER PRODUCTIVITY (IUP)
w
-HUMAN-INTENSIVE COMPONENT OF IUP
7 MEASURED DATA (HUMAN-INTENSIVE

E 500 -
A
z " COMPONENT)
U
E

-
w
E 0

>
-
>
- -
400
3
n
F
2
0
0

300 -

200 -

100 -
0

0- I 1 I I I
0 1 2 3 4 5
COMPUTER RESPONSE TIME (SI

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

There’s a study fromThe human-intensive component of IUP is computed by using between
IBM in 1981 that shows strong evidence of the relationship
performance and productivity.period 1 interactions, instead of all TSO interactions in more
completed As systems get faster, users get EXPONENTIALLY
productive. Equation 1.

When the number of logged-on users on the systemis small, it is
possible for afew users to have aninordinately large effect on the
aggregate user work, and hence bias theresults.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

http://www.ﬂickr.com/photos/billselak/366692332/

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

Customization


How many people want to customize their word processor?

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


Remember those drag-and-drop, parametric screens?


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.

The turnkey/tuning tradeoff.


Standardized

Easy Impossible

Sloppy Easy
Tailored

Slow, Fast/lean, with
inefﬁcient economies of scale


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 sacriﬁce important differentiators.

http://www.ﬂickr.com/photos/andrewparnell/2738598951/

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.


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.

http://www.ﬂickr.com/photos/oobrien/7597395/

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.)

Security is a...

Reason to avoid clouds
23%
Reason to move to clouds
43%

No opinion
34%

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

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

Budget & operating
constraints
What can you afford to take on?


Airfare

DNS

Cloud

Public
transit

Important
research

Hotel

Aﬀordability

Money spent

Point at which
it’s cheaper to
buy than rent

Time (years)

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.

Money spent

Cheaper to rent
for longer

Time (years)

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.

Unforeseen
costs of owning
Money spent

Time (years)

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.

Money spent

Efﬁciencies from
economies of
scale passed on
to customers

Time (years)

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.

5 year planning horizon

6 months
Money spent

Payoff time

Time (years)

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.

Ease of adoption
How readily will your users take to it?



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


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.


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 ﬁfty, when they’re expected to be fast and
error-free.

http://www.ﬂickr.com/photos/farhannasir/4577508824/


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

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.?

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

Possible delivery strategies
Platforms & business models to choose from.


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

Dedicated On-premise Virtual Third-party
hardware private clouds private clouds public clouds


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

Bare metal
(this is your computer)


First, there’s bare metal.

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

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

Virtual machines
Still yours...


Then there’s virtualization.

http://www.ﬂickr.com/photos/mynameisharsha/4092086880
The
step-‐func7on
nature
of
bare-‐metal
dedicated
machines
doesn’t
distribute
workload
very
eﬃciently.

http://www.ﬂickr.com/photos/h4ck/2413562108/


Virtualization lets us put many workloads on a single machine

http://www.ﬂickr.com/photos/stawarz/3538910787/
Once
workloads
are
virtualized,
several
things
happen.
First,
they’re
portable

http://www.ﬂickr.com/photos/swimparallel/3391592144/
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.

http://www.ﬂickr.com/photos/genewolf/147722350
Which
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

http://www.ﬂickr.com/photos/pinkmoose/3278324276/
Automa7on,
once
in
place,
can
have
a
front
end
put
on
it.
That
leads
to
self
service.

Virtualization divorces the app from the machine.

One on many (or) Many on one
Physical machine
Virtual machine

Virtual Virtual Virtual
Physical Physical Physical machine machine machine
machine machine machine
Virtual Virtual Virtual
Physical Physical Physical machine machine machine
machine machine machine


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.

“Cloudy”
tech.
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”

Virtual private clouds
(feels like yours)


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

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

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.

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


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

http://aws.amazon.com/ec2/pricing/

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.

• 60 seconds per page
Desktop EC2 • 200 machine
Pages 17,481 17,481 instances
Minutes/page 1 1 • 1,407 hours of virtual
# of machines 1 200 machine time
Total minutes 17,481 • Searchable database
Total hours 291.4 26.0 available 26 hours
Total days 12.1 1.1 later
• $144.62 total cost


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.

Machine Web
Image server
Machine instance


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.

DB Machine
Storage
server Image

Machine instance

App Machine
Server Image
Machine instance

Web Machine
server Image
Machine instance


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

DB
Storage server

Machine instance
Bigger
App
machine
instance
Server
Machine instance

Web
server
Machine instance


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

DB
Storage
server

Machine instance

App
Server
Machine instance

Web
server
Machine instance

Load
balancer
Machine instance


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.

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


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.

Shared components

Data Processing platform
Storage
API
Others’ Others’
code code
User Auth
database API
Your Others’
code code
Image Image
functions API Others’ Others’
code code
...
Big Blob Governor Console Schedule
objects API

- 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 (ﬁguring
out what to do next) and a governor (ensuring one program doesn’t use up all the resources)
as well as a console.

http://code.google.com/appengine/articles/load_test_screenshot.jpg

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.

http://code.google.com/appengine/articles/logs_admin.png

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

http://googleappengine.blogspot.com/2010/03/easy-performance-proﬁling-with.html

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


And even their latency when served to people.

http://www.computerhok.nl/JSPWiki/attach/GoogleAppEngine/GAEQuota.png

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

http://www.ﬂickr.com/photos/olitaillon/3354855989/

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.

IaaS and PaaS differences
IaaS PaaS

Any operating system you Use only selected
want languages and built-in APIs

Limited by capacity of Limited by governors to
virtual machine avoid overloading

Scale by adding more Scaling is automatic
machines
Use built-in storage
Many storage options (ﬁle (Bigtable, etc.)
system, object, key-value)


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.

Quota Limit
Governor Apps per developer 10
(usage cap) Time per request 30s
Blobstore (total ﬁle size) 1GB
Maximum HTTP response size 10MB
Datastore item size 1MB
Application code size 150MB

Daily cap Emails per day 1,500
(free quota) Bandwidth in per day 1 GB
Bandwidth out per day 1GB
CPU time per day 6.5h
HTTP requests per day 1,300,000
Datastore API calls per day 10,000,000
URLFetch API calls per day 657,084
http://en.wikipedia.org/wiki/Google_App_Engine

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

i.developerforce.com/index.php/Apex_Code:_The_World%27s_First_On-Demand_Programming_Language

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

Software as a Service
Salesforce.com, Google Apps, Microsoft Ofﬁce
Live, pretty much any ISV still around today.


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.”


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.

How you pay for it
Lots of business models


DIY
You can always write your own stuff.


Open source
Standing on the shoulders of giants


Github analysis by Franck Cuny: http://www.ﬂickr.com/photos/franck_/sets/72157623447857405/

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.


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.

Licensed
software
Oh, how quaint.

http://www.penneydesign.com/
folio_IM_retrogamesmodernthemes.html

Freemium
And other sad, bad portmanteaux


Collaborative Transactional
business business
model User creates model
content
Free Paid

Content becomes
Content remains
part of template
private
library

Engagement, Eventual
Revenues
SEO ranking conversion


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.

Composed application
Stitching together loosely coupled pieces


SaaS
Pay as you go.



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

Adoption
The real risk when the app is a utility



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.


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

“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 efﬁciently among
the overabundance of information sources
that might consume it.”

Herbert Simon

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

http://www.ﬂickr.com/photos/gideon/6582069/

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.

http://www.ﬂickr.com/photos/roebot/4271975019/
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.

How do you ﬁx this?


Analytics.


ATTENTION ENGAGEMENT CONVERSION

NEW
VISITORS

SEARCHES GROWTH CONVERSION
PAGES TIME RATE
TWEETS NUMBER
OF VISITS
PER ON x
MENTIONS VISIT SITE
GOAL
ADS SEEN LOSS VALUE
BOUNCE
RATE


Here’s the simplest possible analytics model.

For transactional sites

Can people buy things?


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.

For media sites

Are ads loading quickly and successfully clicked
through?
Is content loading fast enough for visitors?


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.

For collaboration sites

Can visitors contribute (posting content, voting?)
Is bad content being mitigated (trolling, spam)?


On these sites, visitors generate the content themselves. Wikis, news aggregators, user
groups, classiﬁed 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.

For SaaS sites

Are your end users productive?
Are they making fewer mistakes?
Is the site working during customers’ business hours?


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.

Enterprise subscriber $

1

End user (employee) $
Refund $
2

Renewal, upsell, SLA
reference SaaS site violation
Performance
Good Bad 3
Helpdesk Support
5 $
Usability escalation costs
7
4
Good Bad

Productivity
Good Bad

6

Churn $
Impact on site
$ Positive $ Negative


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.

(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?

What does your adoption and usage map look like?

The cycle of optimization
Metrics & strategy

Optimization
Collection
& change

Link to KPI/
Reporting
ROI

Institutionalizing
the results

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

The good news:
you can experiment easily

We stop worrying about ROI when I is zero.


http://www.ﬂickr.com/photos/steven_wong/2440355239/
They’re not dictating and restricting; rather, they’re regulating usage to ensure a good balance of risk and experimentation

Beyond adoption: outcomes

Business
Deployment Awareness Adoption
outcomes


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.

One ﬁnal thought
Paving the cowpaths


http://www.ﬂickr.com/photos/jelles/2902422030/
One approach is to “pave the cowpaths.”

http://www.ﬂickr.com/photos/32314864@N02/3253051215/
This is an old civil engineering trick: Watch where people walk, then put paths there.

The next 3 days
The inside-out organization: Connecting to
Tuesday

customers and markets
Mobile Platforms and Enterprise Agility

The Politics of Delivery: Compliance and
Wednesday

Governance
Platform Options in the New IT Landscape
Social Behavior, Usage Patterns, and Adoption

Can IT Lead the Social Business Strategy
Thursday

Formulation Process?
Delivery Strategies: The Road Ahead

Thanks!
@acroll
alistair@bitcurrent.com


Delivery Strategies: From Idea to Deployment

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (6)

Similar to Delivery Strategies: From Idea to Deployment

Similar to Delivery Strategies: From Idea to Deployment (20)

More from Alistair Croll

More from Alistair Croll (20)

Recently uploaded

Recently uploaded (20)

Delivery Strategies: From Idea to Deployment