1. Cloud Computing and SOA Convergence in
Your Enterprise
DAVID
S.
LINTHICUM,
CTO
BICK
GROUP
February
9th,
2010
safaribooksonline.com

2.
“Cloud
compu>ng
is
a
pay-­‐per-­‐use
model
for
enabling
available,
convenient,
on-­‐
demand
network
access
to
a
shared
pool
of
configurable
compu>ng
resources
(e.g.,
networks,
servers,
storage,
applica>ons,
services)
that
can
be
rapidly
provisioned
and
released
with
minimal
management
effort
or
service
provider
interac>on.
This
cloud
model
promotes
availability
and
is
comprised
of
five
key
characteris@cs,
three
delivery
models,
and
four
deployment
models.”
-­‐
NIST
2

3. Key
Characteris@cs
• On-­‐demand
self-­‐service.
• Ubiquitous
network
access.
• Loca:on
independent
resource
pooling.
• Rapid
elas:city.
• Pay
per
use.
3

4. The
Basic
Idea
SOA Cloud
Finance/
Operations
Resources
Sales Order
Update
New
Accounts
Commission
Calculation
Data
Cleaning
Sales
4

5. Organizing
the
Clouds
Testing-as-a-Service
Management/Governance-as-a-Service
Application-as-a-Service
Integration-as-a-Service
Security-as-a-Service
Process-as-a-Service
Platform-as-a-Service
Information-as-a-Service
Database-as-a-Service
Storage-as-a-Service
Infrastructure-as-a-Service

6. IT
is
Skep@cal
• Enterprise
IT
is
understandably
skiMsh
about
cloud
compu>ng.
• However,
many
of
the
cloud
compu>ng
resources
out
there
will
actually
provide
beOer
service
than
on-­‐premise.
• Security
and
performance
are
s>ll
issues.
6

7. Making
the
Business
Case

8. On-­‐Premise
$1,000,000
$500,000

9. Cloud
Delivered

10. However,
Not
So
Fast
• Not
all
compu>ng
resources
should
exist
in
the
clouds.
• Cloud
compu>ng
is
not
always
cost
effec>ve.
• Do
your
homework
before
making
the
move.
10

11. When
Cloud
Compu@ng
may
be
a
Fit
• When
the
processes,
applica>ons,
and
data
are
largely
independent.
• When
the
points
of
integra>on
are
well
defined.
• When
a
lower
level
of
security
will
work
just
fine.
• When
the
core
internal
enterprise
architecture
is
healthy.
• When
the
Web
is
the
desired
plaVorm.
• When
cost
is
an
issue.
• When
the
applica>ons
are
new.
11

12. When
Cloud
Compu@ng
may
not
a
Fit
• When
the
processes,
applica>ons,
and
data
are
largely
coupled.
• When
the
points
of
integra>on
are
not
well
defined.
• When
a
high
level
of
security
is
required.
• When
the
core
internal
enterprise
architecture
needs
work.
• When
the
applica>on
requires
a
na>ve
interface.
• When
cost
is
an
issue.
• When
the
applica>on
is
legacy.
12

13. Start
with
the
Architecture
Understand:
• Business
drivers
• Informa>on
under
management
• Exis>ng
services
under
management
• Core
business
processes
13

14. Stepping
to
the
Clouds
1.
Access
the
business.
10.
Iden>fy
candidate
processes.
2.
Access
the
culture.
11.
Create
a
governance
strategy.
12.
Create
a
security
strategy.
3.
Access
the
value.
13.
Bind
candidate
services
to
data
and
4.
Understand
your
data.
processes.
5.
Understand
your
services.
14.
Relocate
services,
processes,
and
6.
Understand
your
processes.
informa>on.
15.
Implement
security.
7.
Understand
the
cloud
resources.
16.
Implement
governance.
8.
Iden>fy
candidate
data.
17.
Implement
opera>ons.
9.
Iden>fy
candidate
services.
14

15. Data
Data
On Premise Application
Internet
Services
Cloud-Based Application
Data
Data

16. On Premise
Cloud Provider

17. On Premise
Cloud Provider

18. On Premise Cloud Provider

19. Policies
Policies
Runtime
Governance
Monitoring
Repository
Logs

20. Data Services Processes
Data
Data
Data
Data

21. Data Services Processes
Data
PaaS
Data
Data
Data
DaaS IaaS

22. Data Services Processes
Application
Data
PaaS
Data
Application
Data
DaaS Data
IaaS

23. Other
Thoughts
• External
cloud
services
should
func>on
like
any
other
enterprise
applica>on
or
infrastructure
resource.
• You
should
evaluate
cloud
providers
using
similar
valida>on
paOerns
as
you
do
with
new
and
exis>ng
data
center
resources.
• Cloud
resources
should
appear
na>ve.
• Consider
Private
Clouds.
• Watch
the
hype,
the
resources
are
new,
but
the
paOerns
of
architecture
are
familiar.
23