ICF - The Framework For Cloud Business Revolution - v1

The ICF Whitepaper, Version 1.
0
October 2010
The ICF Whitepaper, Version 1.0
October2010
Contents
Abstract ......................................................................................................................................................... 3
Introduction .................................................................................................................................................. 3
Cloud Business Collaboration - New Business Opportunities ....................................................................... 4
Cloud Business Service – SOA included, WOA presented, EOA enabled ...................................................... 5
Computing Evolution or How did we get here ............................................................................................. 6
Why do we need Cloud Framework? ............................................................................................................ 8
The ICF vs. Enterprise Architecture – the Great Symbiosis .......................................................................... 8
Who should use ICF and why? .................................................................................................................... 10
The Integrated Cloud Framework (ICF)....................................................................................................... 11
The ICF Component Re/Sources ................................................................................................................. 12
The ICF Deliverable Documents .................................................................................................................. 13
ICF Models and Views ................................................................................................................................. 14
Providers and Services – Foundation of the ICF ......................................................................................... 15
Cloud Essentials - Characteristics................................................................................................................ 17
Cloud Business Ecosystem .......................................................................................................................... 18
Cloud Business Service Offer Lifecycle ........................................................................................................ 19
Cloud Buying Lifecycle ................................................................................................................................ 21
Cloud Business Search Lifecycle .................................................................................................................. 22
Cloud Business Mediation Lifecycle ............................................................................................................ 23
Cloud Service Design Lifecycle .................................................................................................................... 24
Cloud Business Mashup Lifecycle ............................................................................................................... 25
Cloud Service Orchestration Lifecycle......................................................................................................... 26
Cloud Catalog – The Cloud Business Proposal ............................................................................................ 29
The Service Measurement Index – a Method for QOS ............................................................................... 34
Cloud Service Seller – 6 Key Metrics ........................................................................................................... 35
Consumer Privacy – The New Cloud Security Layer ................................................................................... 37
Absolute Multi-tenancy or The story about Massive Computing. .............................................................. 41
XaaS reference Model and Multi-tenancy reference Model ...................................................................... 43
Multi-tenancy Isolation Spheres ................................................................................................................. 52
Cloud Business Environment Encapsulation ............................................................................................... 52
How Cloud reshaped Data Center Architecture ......................................................................................... 53
Cloud Business Symbols .............................................................................................................................. 54
Conclusion ................................................................................................................................................... 55
Table of Figures ........................................................................................................................................... 56
Acronym Key and Glossary Terms............................................................................................................... 58
References .................................................................................................................................................. 59
2|Page
October2010
ICF
The Framework for Cloud Business
Revolution
Vladimir Baranek, Enterprise Architect, Strategy, Architecture & Integration, Capgemini, California, USA
Mark Skilton, Global Director, GAO, Strategy and Service Delivery, Capgemini London, UK
Keywords: Cloud Computing, XaaS, Cloud Business Architecture, Stream Computing, Cloud 2.0, Cloud
Business Framework
Abstract
Extending the prevailing technical perspective of cloud computing, this white paper
shifts the focus from an exclusive technological perspective to a broader
understanding of business opportunities, business value of cloud computing and
overall alignment of X computing within integrated cloud framework.
Introduction
The incoming cloud evolution, represented by latest technologies and new business opportunities,
forces integration of existing cloud services into new areas and upgrades their business proposition into
new spheres. Technology is transforming innovation at its core, allowing companies to test new ideas at
speeds and prices that were unimaginable even a decade ago. They can stick features on Web sites and
tell within hours how customers respond. They can see results from in-store promotions, or efforts to
boost process productivity, almost as quickly. The result? Innovation initiatives that used to take months
and megabucks to coordinate and launch can often be started in seconds for cents. Companies will also
be willing to try new things, because the price of
failure is so much lower. That will bring big changes
for corporate culture making it easier to challenge
accepted wisdom, for instance, and forcing
managers to give more employees a say in the
innovation process. There will be even better
payoffs for customers: Their likes and dislikes will
have much more impact on companies' decisions. In
globally competitive markets, they will ultimately
end up getting products and services better tailored
to their needs. Already, this powerful new capability
3|Page
October2010
is changing the way some of the biggest companies in the world do business, inspiring new strategies
and revolutionizing the research-and-development process.
The Web World and Business Services, as we know them today, will change their face and transform
into integrated Cloud Business Platform supported on various Devices and Enterprise Platforms
(submerged with Enterprise SOA world).
Cloud Business Collaboration - New Business Opportunities

During challenging economic times, local governments and businesses of all sizes are pursuing ways to
decrease costs while making operations as efficient and effective as possible. We believe this is possible
only by effective Cloud Business Collaboration utilizing all communication channels and networks.
We started with emails as a basic element of

communication and continued with faster ways
such as Social Networking to even faster mode
with Short Messaging Platforms (Twitter) and now
we are heading into Information Streams (Live
Media, Augmented Reality). Everything is just
faster and this pattern is coming into Business and
Industry Networks not just as some sort of exotic
characteristic, but crucial capability necessary for
business survival.
We certainly realized changes which leaded to

evolution in Internet world, creating Social
Networks enabled by Web 2.0 technologies, trying
to integrate (in next generation) with other parts
of online world and transforming into packaged solutions with certain characteristics and linked
semantic (Web 3.0). Business networks and Industry networks are looking for new level of collaboration
by focusing on reliable connectivity, interoperability, unlimited resources and business agility.
Especially the last keyword “Agility” is connected

to cloud world with increasing pressure from
corporations, unwilling to spend weeks in
marketing promotion campaigns and releasing
product into market in time of next generation
products released by their competitors. In the real
world, Cloud Business Services exist between Social
and Business Collaborations (Figure #1), including
Industry Services (supported by industry standards,
reference models and semantics).
Figure 1: Cloud Collaboration Model
4|Page
October2010
Cloud Business Service – SOA included, WOA presented, EOA enabled

There were a lot of discussions whether the cloud is just evolution of SOA with advanced “On Demand”
characteristics or this is the global mainframe we always wanted (with unlimited capabilities). We tend
to partially agree with both opinions. Probably we should rephrase it into this statement: “The new
generation of Cloud will contain complex, business oriented architecture composited from various XaaS
components and orchestrated by SOA-like technologies into single Cloud Business Services “.
Figure 2: Business Service Orchestration
But what about the Web 2.0 architecture? Where it fits? We can surely ask ourselves variety of
architecture related questions (such as - where is my RIA), but in the reality all of them will end up at
different Enterprise Architecture layers, domains and aspect areas, leaving the major question
unanswered: “If Cloud is the technology of future (no doubt about that), what we have to do in order to
align Cloud World with Enterprise and Social Worlds? How we can connect them bringing their valuable
assets together and leaving technology obstacles behind? ”
Well, we don’t know the best answer. But we suspect the integration of WOA, Grid Computing and
Stream Computing into Cloud World. This Integration is driven by EOA and Social Computing, with
respect to enable and speed up “Business on Demand” without any boundaries.
Major impact of these changes will result in higher price of valuable information, independence from
vendor agnostic solutions, faster and broader data access, new layers of security, firmware free
endpoint devices, global business industry standardization without geographical barriers and many
others.
5|Page
October2010
Computing Evolution or How did we get here

Computing evolution is driven by various requirements, mainly focused on increasing demand for
computing performance, increasing storage and bandwidth requirements, additional networking layers,
adoption of new technologies and business demands. All of these shifts are captured in our 5 layer
Computing Evolution diagram (Figure 3: Computing Evolution). Each Computing version is defined by
Computing Era, designed by Architecture Framework, architected as specific computing architecture and
communicated via specified Network.
The Computing architecture has one common pattern (on conceptual level), which represents Consumer
/ Producer model included in all diagrams (Figure 4: Computing Architectures).
Figure 3: Computing Evolution
1. Centralized Era – First real computing platform (not counting 4-bit and 8-bit personal computers for
home entertainment), utilized Mainframe Computer and Terminals. Local network only and
centralized Solution Design are main characteristics for version 1.
2. Distributed Era – Is described as a first decentralized architecture (client-server) and a major IT
revolution milestone - Discovery of Internet
3. Cluster Era – or Multi-tier architecture allowed even better computing distribution, with negative
side effects such as “spaghetti” architecture problem (Integration complexity). We also recognized
demand for Intranet and Extranet networks and first usage of Enterprise Architecture Framework.
4. Grid Era – clearly effected all Enterprises by SOA – first Service oriented (including Web Service)
Architecture and Parallel distributed computing in Grid.
5. Cloud Era – Business Service Orchestration, XaaS model and demand for Cloud related architecture
framework are just some of the changes escorting the latest development in this area
6|Page
October2010
Figure 4: Computing Architectures
7|Page
October2010
Why do we need Cloud Framework?

As we explored the Consumer – Producer models at previous section (“Computing Evolution or how did
we get here”), we also have to describe this new computing shift which created a new level of
architecture dimension – a dynamic business , software, data and technology structures. It’s a next level
of architecture evolution, heading towards new Cloud related Framework. All dynamic structures (XaaS
Services, Clouds, Cloud Networks and Cloud Business Actors) are concentrated outside of common
frameworks, exposed and undefined. The reason for this implication is based on their dynamic behavior
which prevents their definition in any enterprise domain for a simple reason: Each service could be
placed in any of enterprise domains or in multiple domains at the same time. It’s not predictable,
because of service encapsulation and orchestration. Moreover, Cloud Business Actors are not stable
from role perspective for similar reason and sometimes they tend to fulfill more roles in the same time
in dependency of Cloud Environment, Cloud Network and service deployment position.
Figure 5: Cloud Components and Enterprise Framework
Figure 5: Cloud Components and Enterprise Framework shows overall situation depicting EA
Architecture and EA Domains as static components and XaaS services, Clouds, Cloud Networks and
Cloud Business Actors as Dynamic Components.
The ICF vs. Enterprise Architecture – the Great Symbiosis

The ICF framework doesn’t make previous frameworks obsolete or not capable of architecture solution
definitions created for Cloud world, it’s just adding new dimension for Public, Enterprise, Hybrid and
Private environments by exposition of dynamic business, social and Industry networks in one
consolidated dynamic framework. Enterprise, Solution and Cloud frameworks are complete together
and serve various purposes during all Business Lifecycle Stages (Develop, Integrate, Deliver, Sell, Buy,
Use) inside Cloud Business Ecosystem (Figure 13: Cloud Business Ecosystem View). This great symbiosis is
described in Figure 6: Dynamic and Static Frameworks and shows connections between Dynamic and Static
Frameworks.
8|Page
October2010
The ICF Framework is directly connected to CORA (Common Reference Architecture), for easy
implementation of vendor related Solution Architectures in Cloud World, and to any open Enterprise
Architecture Framework such as TOGAF (The Open Group Architecture Framework), IAF (Integrated
Architecture Framework) or governance framework FEAF (Federal Enterprise Architecture Framework).
ICF Cloud Actors

Dynamic Frameworks
IAF Cora Togaf

Static Frameworks
SAP IBM Microsoft
Legend: Cloud Framework Enterprise Framework Solution Framework
Figure 6: Dynamic and Static Frameworks – The Great Symbiosis
Conceptual Architecture for ICF should leverage specific Cloud Business Symbols (Figure 48: Cloud Business
Symbols ) and support Archimate (Enterprise Modeling Language) for inter- framework interoperability
purposes.
9|Page
October2010
Who should use ICF and why?

The ICF Framework should be used for following purposes:
 Monetizing Cloud Services - Adoption question; “how much do cloud services cost my
business?” Defining a way to show individual services and their common shared service or
incremental growth could help accelerate an adoption profile where users understand the cost
of service better.
 Visualizing the Real Cloud - Business Stakeholders needs a way of describing this from different
Viewpoints and Perspectives so that we can accelerate the meaning full integration and
adoption of cloud into everyday experience.
 The Cloud Business Architecture Enabler - by utilization of High Level Views such as Strategy ,
Vision, Concepts and definition of overall Cloud Business Solution Architecture
 Cloud Service Consumer Experience by specification of security, privacy and user experience
models
 Quick and Easy Adoption – by ICF specified Models and Views into real world
 Scalability and EA Integration – adding dynamic aspect into enterprise architecture and
scalability at business level
Figure 7: Who should use ICF and Why
10 | P a g e
October2010
The Integrated Cloud Framework (ICF)

Increasing demand for globalization and business abstraction of existing business categories leads to
broader usage of business industry reference models and standardization of business process models
supported by developed standards (ebXML), semantics (UDF) and existing enterprise architecture
frameworks (Togaf). As a result, we identified missing cloud business related objects, business notation
and framework which puts all this components together and enables “Cloud Business Service on
Demand”. We call it “Integrated Architecture Framework”. This framework supports new building blocks
such as next generation of XaaS components, Cloud Business Orchestration and Cloud Business Actor
Ecosystem.
Figure 8: The Integrated Cloud Framework
The ICF’s core structure is composited from three Levels, six Domains, numerous Silos and their
Elements. The Framework itself doesn’t represent all possible elements. We believe in iterative process
and continuous evolution of existing terms and dynamic structures, progressively changing behavior and
functionality of specified building blocks and deliverables.
The ICF is “Open” Cloud Framework, or in other words it’s open to cooperation/reference from/to any
domain/level/segment oriented frameworks such as Jericho Forum Security Cube for Cloud, Cloud
Buying Lifecycle (Open Group) etc.
11 | P a g e
October2010
The ICF Component Re/Sources

All ICF Components are connected together via component variables - Re/Sources. These Re/Sources are
quantifiable and measurable inputs/outputs which represents Component Service Status Values -
Re/Sources available for particular component. The Re/Sources can be managed by following functions:
1. SET – to Configure Particular Component or Cloud Business Service (Orchestrated)

2. GET – to View Business Service or Component Status and predict future Component or Service
behavior.
Figure 9: The ICF - XaaS Component Re/Sources
The ICF Component Re/Sources are input values for all Cloud Related Processes, Planning, Lifecycles,
Metrics, QOS, SLA etc. The Connectors represents methods, how to “GET” or “SET” Re/Sources in
particular XaaS component and also shows Interconnections/Dependencies between XaaS components.
The ICF Framework, at the top of the Component Structures, collects and holds all these Cloud related
objects and will refer to relevant methods and calculations for Service Configuration, Status Map and
Service utilization prediction. All Input / output values are measurable and configurable within related
Time Frame – general variable which has 3 time zones (past, present, future).
12 | P a g e
October2010
The ICF Deliverable Documents

The ICF define minimum set of deliverable documents for cloud reference architecture. Every document
specified in this set is optional. The ICF deliverable documents are dedicated to different stakeholders,
hence each document represent different viewpoint and focused. Scale and Abstraction of each
document is driven by various variables such as architecture level, time constraints, audience level,
coherency and granularity of input values for strategy and vision layers etc.
Deliverable Documents ( Highlighted ) specified below are organized by ICF Domains and Levels:
A) Domains
1. “Business” Domain
 Business Scenarios
 Business Use Cases
 Industry Reference Models
2. “Security” Domain– Cloud Security Layers
 Jericho cloud Cube Domains – Security Model
 Consumer Privacy layer – Privacy Model
3. “Clouds” Domain – Cloud Categories
 Cloud Environments – Deployment Model
 Cloud Networks - Collaboration Model
 Cloud Domains – Domain Model
 Cloud Essentials Domain – Cloud Characteristic Definitions
4. “Actors” Domain– Cloud Business Actors
 Cloud Business Ecosystem Model , consist from Business Lifecycle Views and their
deliverables
o “Develop” Activity View – Cloud Service Development Lifecycle
o “Integrate” Activity View – Service Integration and Orchestration Lifecycle
o “Deliver” Activity View – Delivery Lifecycle
o “Sell” Activity View - Business Service Offer Lifecycle
o “Buy” Activity View - Buying Lifecycle
o “Use” Activity View - Business Service Consumption and Configuration Lifecycle

5. “Services” Domain– Cloud Services
 XaaS Category Services – Component Model
 Business Services:
o Business Orchestration Model
o Business Service Lifecycle Model
o Cloud Service Catalogs
o Business Mashup Model
6. “Technology” Domain – Cloud related Technologies and Architectures
 Technologies - Technology Map
 Architectures – Architecture Map
13 | P a g e
October2010
B) Levels:
1. Solutions – Cloud Business Solution Architecture
2. Cloud Solution Visions – Discovery of new Business Services and Markets
3. Cloud Business Strategies - Business Strategy Blueprint
4. Cloud Concept Diagrams and Symbols - Business Conceptual Architecture
5. Cloud Solution Views with various Viewpoints for different Stakeholders
ICF Models and Views

The ICF Framework offers 2 main referential areas – Models and Views. These models and views can be
reused and referenced in any Cloud related architecture.
Figure 10: ICF Models and Views
14 | P a g e
October2010
Providers and Services – Foundation of the ICF

The Providers and Services view is focused on business providers linked to cloud providers and XaaS
service providers representing three major building blocks as enablers of new integrated cloud business
services.
Figure 11: Providers and Services Model
Note: The Notation in Figure 11 distinguish between “Cloud v1” – Already established cloud services and
“Cloud v2” – New generation of services, identified during development of ICF.
1. Cloud Providers have to execute and Manage Common Shared Services and Operating Services in
order to provide any Cloud Service. These well-known business blocks contain EA capabilities divided by
domains with specific focus on overall Cloud Service Capabilities Management.
2. Building Blocks of Cloud Businesses are located inside “Business Providers” block:
 Business Service Offer – offers Cloud Business Services based on Cloud Service Catalog
 Business Search – supports Cloud Business Discovery Services by execution of query above local
and distributed cloud service catalog (query parameterization)
 Business Mediation – is responsible for mediation and propagation of Cloud Business Service
into local and distributed Cloud Service Catalogs
15 | P a g e
October2010
 Business Mashup – is top level of business orchestration, which provides Business Service
Aggregation and Parameterization.
 Cloud Service Orchestration – represents orchestration of service components (XaaS), based on
Component Catalog
 Cloud Service Catalog - is essential part for all other blocks. It’s owned and distributed by Service
Mediator.
3. Some of the XaaS Service Category Providers are already recognized and described in existing Cloud
Taxonomies and Architectures (NIST Cloud Definition Framework, Cloud Computing Ontology by UC and
IBM), these are marked in our ICF framework as “Cloud V.1”. Additionally we specified missing XaaS
Categories which are fully used in this framework as Cloud Components necessary for Cloud Business
Orchestration and we are convinced they will appear on Cloud Market in short time.
Figure 12: The XaaS Service Category definitions and Examples
There are additional services identified by various groups such as “Computing as a Service”, “Network as
a Service”, “Storage as a Service” and so on. However, we believe that those are just sub-services,
residing inside major services, already identified at ICF XaaS Service Category Model. As an example,
storage is infrastructure component so it’s covered by Infrastructure as a Service.
16 | P a g e
October2010
Cloud Essentials - Characteristics

Cloud Characteristics were defined and revisited by many groups. This task is certainly not finished,
taking into consideration latest development in Cloud World. However Cloud Characteristics defined by
National Institute of Standards and Technology (NIST) is foundation for Essential Characteristics of ICF.
1. Essential Characteristics
 On Demand Self Service - A consumer can unilaterally provision computing capabilities,
such as server time and network storage, as needed automatically without requiring
human interaction with each service’s provider
 Broad network access - Capabilities are available over the network and accessed
through standard mechanisms that promote use by heterogeneous thin or thick client
platforms (e.g., mobile phones, laptops, and PDAs)
 Multi-tenancy or Resource pooling - The provider’s computing resources are pooled to
serve multiple consumers using a multi-tenant model, with different physical and virtual
resources dynamically assigned and reassigned according to consumer demand. There is
a sense of location independence in that the customer generally has no control or
knowledge over the exact location of the provided resources but may be able to specify
location at a higher level of abstraction (e.g., country, state, or datacenter).
 Rapid elasticity - Capabilities can be rapidly and elastically provisioned, in some cases
automatically, to quickly scale out and rapidly released to quickly scale in. To the
consumer, the capabilities available for provisioning often appear to be unlimited and
can be purchased in any quantity at any time.
 Measured Service - Cloud systems automatically control and optimize resource use by
leveraging a metering capability at some level of abstraction appropriate to the type of
service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage
can be monitored, controlled, and reported providing transparency for both the
provider and consumer of the utilized service.
2. Common Characteristics
 Massive scale and Redundancy
 Pay as You Go with SLA support
 Virtualization and Architecture Resiliency
 Advanced Abstraction
 Non-stop computing
 Free software and data
 Portability and component integration
 Inter-Cloud Interoperability and Cloud Bursting
 Geographic distribution and localization
 Service oriented software and Open APIs
 Autonomic computing
 Advanced security technologies
17 | P a g e
October2010
Cloud Business Ecosystem

Cloud Business Ecosystem is first and most important view depicted in Figure 13: Cloud Business Ecosystem
View, summarizing overall abstraction on Business Actor and Role level.
The ICF Cloud Business Ecosystem offers transparent method for general overview about all Cloud
Business Processes and their Actors, divided into 6 Major Activities / Lifecycles, 10 Actors and 3
Deliverable Zones.
Figure 13: Cloud Business Ecosystem View
Activities & Actors – Collection of lifecycles:
1. Develop – Service Developer develops Cloud Service

2. Integrate – Integration is provided by Service Integrators , Service Hypervisor and Service
Mediators & Publishers
3. Deliver – Service Delivery is executed by Service Provider and Service Distributor. Delivery of
Service Content is provided by Content Distributor
4. Sell – Service Seller is responsible for Service Marketing and Service Deal based on Service Offer
5. Buy – Service Buyer owns Purchased Service with SLA
18 | P a g e
October2010
6. Use – Service Consumer uses Cloud Service
Deliverable Zones:
1. Business Service – is developed by Developer, delivered by Service Provider, integrated by

Service Hypervisor and published by Service Mediator/Publisher as Part of Service Catalog
2. Service Catalog – is published by Service Mediator/Publisher. Service Integrator orchestrate this
service (based on Cloud Component Catalog) as a Component of more Complex Cloud Service
and Uses Service Mediator/Publisher in order to propagate this service as part of Cloud Catalog.
Cloud Catalog also shows availability of particular Cloud service, which is Service Distributor able
to deliver into different cloud segments (environments, zones). Content Distributor captures
Information Streams and delivers (query, aggregate and replicate) information on demand
based on Service SLA as part of Cloud Service Catalog.
3. Service Offer – is made by Service Seller, based on Service Catalog. Service Seller can support
different SLAs (based on marketing campaign) and is responsible for marketing, accounting and
maintenance of existing deals (aligned with SLAs).
The Cloud Business Service is central element of Cloud Business Ecosystem view, integrating all actors,
activities, technologies, layers and architectures for one business reason - attract and sell this service on
demand to potential cloud buyer. Cloud Buyers and Consumers are affecting Business Service
consumption and configuration, which are input parameters for cloud usage forecasting and demand
prediction affecting new releases of cloud services and adding values to overall cloud orchestration and
Mashup services.
Figure 14: Activity deliverables
19 | P a g e
October2010
Cloud Business Service Offer Lifecycle

Is based on Cloud Catalog and can have various granularity on vertical (XaaS categorization) and
horizontal (business silos) levels reflecting available SLAs and marketing campaigns. Cloud Business
Buyers are naturally not concerned about technology constraints hidden costs. Cloud Business Offer is
focused on Service SLA, QOS (Reference #4), Service Parameterization, overall Service Offer and ongoing
Service Status. The following diagram (Figure 15: Cloud Business Service Offer Lifecycle) shows lifecycle of
Business Service Offer and encapsulation of Business Service from Business Owner (Buyer) point of view
and his limited visibility on SLA, Parameters and Status only.
Figure 15: Cloud Business Service Offer Lifecycle
As depicted above, there are five major phases of Cloud Business Service offer :
 Phase I. - Cloud Business Service Offer provided by Service Seller (based on Sellers portfolio
collected from Cloud Catalog)
 Phase II. - Service is sold to Business Buyer, deployed into Target Area (In case it’s not already
done) based on Cloud Catalog Targets, Configured accordingly to SLA parameters (core) and
Business differentiator related parameters (optional, extended parameters) and Initiated.
 Phase III. - Service runs on demand, reflecting core and extended parameters, fulfilling SLA and
providing Service Status via designated channels and tools (consoles).
 Phase IV. - Service respond on changed configurations and is manageable by business owner
 Phase V. – Service is Terminated by Service Provider, Erased from Target Area, content is kept in
archive based on Retention Period
20 | P a g e
October2010
Cloud Buying Lifecycle

Cloud Buying Lifecycle segments Cloud Buying Process into manageable Phases and covers “internal-
internal” and “internal-external” transactions depicted below.
Figure 16: Cloud Buying Lifecycle
Cloud Buying Phases are described as:
 “Determine Fit”: determine if buyer’s objectives and seller’s capabilities align

 “Establish Requirements”: establish requirements for – and obstacles to – cloud
 “Negotiate”: negotiate transaction terms and conditions,
 “Manage Performance”: measure and assess results
Deliverables ( Highlighted ), categorized by Phase, shows complexity of buying process and

dependencies between them:
 “Determine Fit”: Cloud Buyers’ Decision Tree, Building ROI from Cloud, Cloud Business Patterns
 “Establish Requirements”: Questionnaire and Taxonomy Introduction, Cloud Buyer’s
Requirements Questionnaire, Cloud Business Usage Framework, Cloud Requirements: Buyer’s
Guide, Buyer’s Cloud Taxonomy, Cloud User Profiles
 “Negotiate”: ROI, Risk, QoS and Impact Measurements, Using Cloud to Mitigate Risk, ROI
Assessment
 “Manage Performance”: RFI / RFQ / RFP Input, ROI, Risk, QoS, and Impact Scorecards
21 | P a g e
October2010
Cloud Business Search Lifecycle

Sooner or later (sooner is better), we will quickly realize that we reached the same problem with cloud
business services as we have today with internet web pages / e-commerce shops – they are everywhere.
Digital Market is the biggest one and one size fits all (especially in Cloud World).
The Cloud Business Search capability acts as a Business Discovery Service with quick search inside
various Catalogs, preferably in following sequence:
1. Internal Cloud Business Catalog

2. Internal Cloud Component Catalog
3. External Mediated Cloud Business and Component Catalogs (Subscribed)
Figure 17: Cloud Business Search Lifecycle
It’s very similar to the Internet Search as we know it today (Google or Bing searches above their
“Catalogs” – tagged metadata), using sophisticated algorithm to do the job fast and with relevant result.
Well, relevant result doesn’t guarantee explicit semantics and more over there is that problem with
Search Engine Optimization (SEO) and market behind it. In other words, this is just next Cloud Business
enabler for Business Service Marketing (promotions inside Catalog) - based on Consumer’s search
criteria and his/her preferences. This provides endless options not just for basic Cloud Business Search
but also for “Integration on Demand” (Dynamic Cloud Orchestration), for Cloud Content Mashup (DaaS)
and Industry Component selection (based on equal Service Parameters) .
22 | P a g e
October2010
Cloud Business Mediation Lifecycle

Cloud Business Mediation is process focused on publishing registered Cloud Business Services to Cloud
Business Search for Business Discovery purposes. The process is depicted below.
Figure 18: Cloud Business Mediation Lifecycle
At the start, Cloud Service Provider generates a Cloud Service Definition File (CCSDL) and sends it to
Service Publisher. Service Publisher collects all CCSDAL files (from all Providers) and generates Service
Manifests – Collection of files categorized by Business segments and Industries. These Service Manifests
represents two Catalogs – Business Service Catalog and Component Catalog. As a next step, Service
Publisher publishes his catalogs to Service Mediators (based on Catalog Subscriptions). Cloud Service
Mediators collects Catalogs from all Service Publishers and aggregate catalog content into one
Component Catalog and one Business Service Catalog. These Catalogs are enhanced with various search
Hints (metadata tags aligned with Cloud Sematic Platform) and Business Affiliation Information
supported by Service Seller. Service Seller also provides Advertising / Marketing Information for Cloud
Business Search Service in order to prioritize Search Results.
Let’s imagine, we are searching for business service which will provide franchising of end-to-end “T-
Shirt” business (Development, Design, Shop, Manufacture, Logistic, and Financial). Service Seller will
gladly pay to Service Mediator for Affiliation and to Business Search Service for prioritization of Business
Service inside Search Result.
23 | P a g e
October2010
Cloud Service Design Lifecycle

Component Design Lifecycle is (as you would expect) different from tradition Design/Development
Lifecycle. Overall process is generalized and defined below.
Figure 19: Cloud Service Design Lifecycle
In first phase, Cloud Service Developer collects Service Requirements (Business, Technology and
Content) and Specify Service Design Document. In next phase he develops new Cloud Service from
scratch or reuse existing Component or Service Template. As in traditional Development methodologies,
product is tested in various environments (UAT,FAT etc.) and released as Cloud Service build / assembly
together with Service Documentation and CCSDL File (Service Definition File) for propagation purposes.
Service Provider receives Service Build and Service Definition Files and Deploys Service into Target
Environment (based on Internal Catalog of Targets). Next two phases are dedicated to Configuration and
Management of Deployed Services (both phases are ongoing) which includes Service Maintenance,
Monitoring and Decommission.
Service Publisher receives updated CCSDL files with latest status and supported parameters and
aggregates them with incoming CCSDL files from other Cloud Providers into Service Manifest. Service
Manifest is published to Service Mediator and after additional processing mediated as part of Cloud
Catalog.
24 | P a g e
October2010
Cloud Business Mashup Lifecycle

Cloud Business Mashup enables orchestration of Business Services. It’s a final top level of Business
Abstraction which concentrates on Business aggregation, consolidation, advanced content delivery and
promotes new Business Differentiator Methods and approaches.
Figure 20: Cloud Business Mashup Lifecycle
In First Phase, Service Integrator Loads all Service Assets accessed during Design Phase into Internal
Catalog of Targets. Mashup Design is fully dependent on Services from Catalog of Targets. Target
Services are used in Service Orchestration model as Orchestration Sources and Targets (Similar to SOA
orchestration). It’s Cloud version of BPEL with advanced configuration options and parameterization.
As in traditional Development methodologies, product is tested in various environments (UAT,FAT etc.)

and released as Cloud Service build / assembly together with Service Documentation and CCSDL File
(Service Definition File) for propagation purposes.
Monitoring and Decommission. Service Publisher receives updated CCSDL files with latest status and
supported parameters and aggregates them with incoming CCSDL files from other Cloud Providers into
Service Manifest. Service Manifest is published to Service Mediator and after additional processing
mediated as part of Cloud Catalog.
25 | P a g e
October2010
Cloud Service Orchestration Lifecycle

Cloud Service Orchestration Lifecycle shows orchestration of Cloud Service Components (XaaS) into
single Cloud Business Service with heavy usage of Component Catalog as source of all Component
related information.
Figure 21: Cloud Service Orchestration Lifecycle
In First Phase, Service Integrator Loads all Service Assets accessed during Design Phase into Internal
Catalog of Targets. Service Orchestration Design is fully dependent on Components from Catalog of
Targets. Target Services are used in Service Orchestration model as Orchestration Sources and Targets.
Their orchestration ability depends on their XaaS categorization. As a result, orchestrated Service
contains generalized aggregation of their SLAs and QoSs (part of Service Manifest).
Overall, the Cloud Service Orchestration Design is complex process which needs to be supported by
relevant design tools and technologies.
As in traditional Development methodologies, product is tested in various environments (UAT,FAT etc.)

and released as Cloud Service build / assembly together with Service Documentation and CCSDL File
(Service Definition File) for propagation purposes.
26 | P a g e
October2010
Monitoring and Decommission. Service Publisher receives updated CCSDL files with latest status and
supported parameters and aggregates them with incoming CCSDL files from other Cloud Providers into
Service Manifest. Service Manifest is published to Service Mediator and after additional processing
mediated as part of Cloud Catalog.
Overall, the Cloud Service Orchestration Design is complex process which needs to be supported by
relevant design tools and technologies.
Diagrams depicted below shows example how the Cloud Component Orchestration could look likes,
utilizing all XaaS categories. Decomposition shows Integration inside and outside of orchestrated
Business Service.
Figure 22: Cloud Service Orchestration Decomposition- Inside The Service CUBE
27 | P a g e
October2010
Figure 23: Cloud Service Orchestration Decomposition- Outside the Service CUBE
Description of Example:
1. Business Service: We can buy a Cloud “T-Shirt” Company (BaaS) and differentiate our Cloud
Service by specific differentiator ("Green" materials, "Lighting" features etc.)
2. Cloud Business Composition (encapsulated) :
 “T-Shirt” e-shop - running on Amazon (SaaS), eBay (SaaS), CafePress (PaaS)
 Social Networking - Facebook Group, Twitter messaging (status of order etc.) for business
awareness and marketing purposes (PaaS)
 Marketing - Banners on Youth / Gaming web sites , inside Facebook Games (Farmville,
YoVille) or other Cyberspace Worlds (Second Life) - (INaaS)
 Physical Producer of T-Shirt - Cloud based order from factory or from Warehouse (ebXML,
advanced Edifact or similar B2B service)
3. Cloud Business Service Orchestration
 Utilization of Industry Interoperability Services (Marketing, Delivery, Financial
 Real-time Cloud Business Status Monitoring
All together - this is a T-Shirt cloud (business) provided by some Business Company as Service on
Demand. In order to start this cloud service you have to provide Money, choose input parameters, pay
monthly fees (based on chosen parameters (transactions, marketing etc.) and provide content or chose
service which will provide relevant content.
28 | P a g e
October2010
Cloud Catalog – The Cloud Business Proposal

Cloud Catalog is the “Center of Universe” in the Cloud Business World. There are several important
reasons for usage and creation of cloud catalogs:
 Publishing / Mediation of Cloud Services

 Sales Catalog for Cloud Business Offerings (Marketing and Business Proposal)
 Component Integration and Orchestration purposes
 Cloud Service and Content Distribution availabilities
For a Cloud Business Providers, substantial part of the Catalog can serve as their Product Portfolio and
can dynamically change their Business Offers. This represents very important momentum for
promotions of new products and can influence market share revolutionary. This ability to offer new
products with numerous configuration parameters (SLAs) will distinguish between Sellers, supporting
Emerging Technologies without boundaries and Conservative Sellers which depends on their static
product portfolio constructed from their Business Vendor agreements. There is also very distinct parallel
between Business and Social Networks. Social Networks are dynamic and Self-Organizing. We believe,
this is the missing piece into mosaic which grants superior importance of Cloud Catalog for new
generation of Cloud Business Networks and it’s a Cloud Business Collaboration enabler.
We recognized three major Catalog types specified below.
Figure 24: Cloud Catalogs
29 | P a g e
October2010
XaaS business enabler – The Component Catalog
The Component Catalog is compiled structure of XaaS services represented by four major component
blocks (Actors, Parameters, Management and Status) per each Component Category (Figure 25: The
Component Catalog).
Figure 25: The Component Catalog
Component Catalog provides basic elements for component orchestration and enables business service
offering – it collects all XaaS together with their Service Parameters, Service Management Options and
provides Service Status. Component Actors are necessary for successful service integration and
provision. Service Parameters covers SLA, QOS and Target Environment (for Deployment) together with
Security, Integration and Governance.
All these together with Service Management and Service Status should be specified in XML based
Language which is not defined yet. For sake of transparency we named this language temporarily as
“Cloud Component Service Definition Language” (CCSDL). The CCSDL should serve in similar manner as
WSDL in SOA world for Service Description, Definition, support Cloud Semantic Platform and many
others. The Content of CCSDL is represents “Cloud Component Service Manifest” for Stand Alone Cloud
Service or Multiple Services (Could contain all catalog components).
30 | P a g e
October2010
Business Service Catalog
Business Service Catalog is compiled structure of Business Services and Business Service Templates
categorized by Business Segments (Figure 26: Cloud Business Service Catalog – Business Segmentation).
Figure 26: Cloud Business Service Catalog – Business Segmentation
Description of Business Service Catalog Elements:
 Business Service and Business Service Template are associated with Business Service Provider
(responsible for SLA and QOS) and Business Seller (responsible for Marketing, Business Service
Offering and Pay as You Go experience).
 Business Service is Encapsulated Business Package, ready for subscription.
 Business Service Template contains already Orchestrated Components, ready to Deploy into
Target Environment (specified in Catalog of Targets) and for Subscription.
 Business Segments divides Catalog into logical groups and together with Industry Categorization
are considered as major search/filter criteria (Business Search Capability)
Business Catalog is further enhanced and categorized by Industries (Figure 27: Cloud Business Catalog –
Industry Segmentation, parameters, Management and Status) with advanced functionality such as:
 Equal QOS (Certified by Industry) within Industry and Business Segment

 Business Processes are aligned with Industry Reference Models
31 | P a g e
October2010
Figure 27: Cloud Business Catalog – Industry Segmentation, parameters, Management and Status
Industry Catalog is highly standardized published by Industry Certification Authorities and fully aligned
with Semantic for particular Industry. Wide usage of semantic (not just in Catalogs) shows dominant
requirements for development of Cloud Semantic Platforms Tailored by Industry and Business
Segments.
Cloud Semantic Platform could be simple Business Service which will guarantee (semantic verification
and usage confirmation) and certify any (Business or Industry Specific) content. This is the only way how
we can guarantee fair comparison of offered business services based on their parameters .
Industry Catalogs and Business Segments are published in releases (refreshed on demand or as part of
subscription).
Business Catalog is a Living Animal, take a look at the all the changes (anytime):
 Services – New, Updated, Deleted

 Service Status – Active, Inactive, Bursting (Not Accepting Subscriptions) etc.
32 | P a g e
October2010
Cloud Catalog Mediation and Usage – Industry Example
Example of Industry Catalog Publishing, Aggregation, Consolidation, Mediation and Usage is depicted in
diagram below.
Figure 28: Cloud Component Catalog Example – INaaS point of view
This example shows Business Service provided by Industry as part of Cloud Catalog (INaaS category),
offered by different Business Corporations and their Interoperability within Industry based on equal SLA
parameters (Certified by Industry Certification Authority, based on QOS quantification process per each
Industry Business Service)
Catalog of Targets
Catalog of Targets is Internal Catalog (not published) owned by Service Provider or Service Integrator.
 Target Cloud Environments contains Reference Target Environment Types (Stacks) for
Deployment of Cloud Services
 Target Cloud Services Catalog is used for Service Orchestration only ( References consumed
Services)
33 | P a g e
October2010
The Service Measurement Index – a Method for QOS

The Service Measurement Index (SMI) is a standard method developed by SMI Consortium for
measuring the end-to-end consumer experience for any number of IT services.
Figure 29: Service Measurement Index - Characteristics
Jane Siegel and Jeff Perdue (Carnegie Mellon) said "We are helping to develop a set of business-centric
measures, mixing quantitative and qualitative data that will provide chief information officers with a
standardized method for comparing cloud services from internal or external providers"
We believe, this could be the baseline for QOS metrics desperately needed in cloud world and could also
tremendously help in INaaS layer to define and provide Interoperability within Industry and overall QOS
measurement for all XaaS Layers. Therefore, it’s essential part of Cloud Catalog and great influencer
inside Cloud Buying Lifecycle process.
Users of the SMI Framework can not only compare cloud service vendors based on their specific
business and technology requirements, they can also make dynamic and real-time decisions (based on
Cloud Catalog – Component Orchestration). This will lead to dynamic Market changes spreading out
portfolio of existing products into separated quality levels and enhance granularity of existing business
processes from SaaS into BPaaS. So, based on the customer/consumer preferences, they can choose
different quality (with different price / benefits) of service and make unseen product combinations
exactly for their needs. This is real Portfolio Mashup categorized by Quality, measured by SMI (as basic
number) and further enhanced into quality level within Industry Standards.
34 | P a g e
October2010
Cloud Service Seller – 6 Key Metrics

Just recently, Ryan Carson defined a list of six key metrics for Web Apps and methods “How to track
them”. We realized, this list is applicable for any XaaS component and could be used as basic
measurement tool for Cloud Service Seller with different definitions per XaaS Component”
Here is the List:
1. Churn
Definition: Churn is the % of customers that cancel each month.
Calculation: number_cancellations_this_month / total_number_paying_customers
Using Churn, you can calculate the Average Customer Lifetime - the average number of months
that a customer stays with you before canceling. The calculation is 100 / churn percentage.
2. CMRR
Definition: CMRR is "Contracted Monthly Recurring Revenue."
Calculation: (total_number_paying_accounts -
number_cancelled_paying_accounts_this_month) * monthly_price
Carson suggests you aim for a monthly growth of around 5% ater Churn in your CMRR. You need
to be sure your CMRR keeps pace with your Churn, otherwise you will start losing money.
3. Cash
Definition: Money in the bank.
Calculation: cash_at_end_of_last_month + (CMRR - total_monthly_costs)
4. LPC
Definition: LPC is "Lifetime Profit per Customer."
Calculation: See the Google Spreadsheet
Carson admits this is a "pretty tricky number to compute," adding that "essentially this helps
you understand how much profit each customer brings you, after all your costs." The figure
takes into account things like Churn and Average Customer Lifetime.
Carson argues that, while this number should grow, if it's too high then it may be an indication
you're not investing enough back into the product. He says that typical numbers for SaaS apps
range from 50-70% net profit.
35 | P a g e
October2010
5. CACR
Definition: CACR is "Customer Acquisition Cost Ratio."
Calculation:
https://spreadsheets.google.com/ccc?key=0AkxZrw3662U_dEhQa0Y4T3c5RU5mcGd6N0twYXhL
ZWc&hl=en#gid=0
This is a ratio that will tell you how long it will take for you to recover your customer acquisition
costs. According to Carson, this is a useful number to gauge how much your are re-investing
back into the product in order to grow the customer base (and by extension, revenue). "If it's
too low, then you're not making enough profit. Too high, then you're not spending enough on
marketing."
6. CPA
Definition: CPA is "Cost per Acquisition."
Calculation: marketing_costs_this_month / number_new_paying_users_this_month
Carson contends that companies are often told to spend more on customer acquisition than
they need to, and he says that he's aiming for around 1-2 months of customer revenue to
acquire a new customer.
Figure 30: Service Measurement Index – Characteristics
There are additional metrics such as Average Revenue per User (ARPU) and Average Revenue per Paying
User (ARPPU), but we consider six metrics defined above as basic elements, which could be enhanced en
dependency of particular XaaS Cloud Seller.
36 | P a g e
October2010
Consumer Privacy – The New Cloud Security Layer

Cloud Security is considered as one of the biggest concerns related to Cloud Computing and has been
identified by numerous Security groups such as Cloud Security Alliance (CSA) and Jericho Forum (Open
Group). In line with continuing strategy for enabling secure business collaboration, the Jericho Forum
defined The Cloud Cube Model consisted from 4 dimensions differentiated from each other and the
manner of their provision. We connected these dimensions with ICF Cloud Actors and adopt them as a
1st line of defense for our ICF Cloud Business Privacy Layer Model.
Figure 31: Cloud Security – Cube Dimensions specified by Jericho Forum
Dimensions are specified as:
1. Internal / External : Physical Location

2. Proprietary / Open : State of ownership and degree of interoperability and transportability
3. Parameterized / De-parameterized : Executing operations within or without IT Perimeter
4. Insourced / Outsourced : Service is provided by own staff or by 3rd party
All Cloud Security Frameworks addressed security issues towards the Cloud Networks and
Environments, which is correct, approach considering the fact that we speak about massive scalability,
virtual environments, complex orchestrations and advanced business collaborations.
37 | P a g e
October2010
With increasing amount of business services, devices, sensors and various channels we identified new
security layer concentrated around Service Consumer, indicating opposite service layer order (from
Cloud towards Consumer) . In the other words, from business perspective we take care about Consumer
Privacy affected by Security Dimensions, Information Channels, Business Services, Information Streams
and Disposable Technologies (new Emerging Trends).
The ICF recognize two Business Security Layers depicted in (Figure 32: Cloud Business Security Layers View),
concentrated around Service Consumer showing “Privacy Level Meter” capability as a primary method
for Privacy Measurement and also as a Capability Enabler for Privacy Configuration of Channels,
Services, Devices and Categories.
Figure 32: Cloud Business Security Layers View
Note: The “Demand your Dot Rights” Organization (ACLU) states: The Consumers of Cloud computing
services have a simple message for their service providers: “Let's keep the data between us”. The
outdated privacy laws, inadequate privacy policies, and lack of technological tools allowing for
consumers to control their own information signal stormy skies for privacy.
38 | P a g e
October2010
The Privacy Level Meter (PLM) measures calculated Privacy Score and provide Consumer Privacy Level as
privacy intrusion indication (Figure 33: PLM – Consumer Privacy Intrusion Level identified by Privacy Score) for
particular person , person type or person role.
Figure 33: PLM – Consumer Privacy Intrusion Level identified by Privacy Score
Privacy Score can be calculated by device or as an overall Privacy Number and is specified as calculation
of:
Here is the example for Privacy Score Calculation:
(510*16*80*2500*1010) = 1648320000000 / (100000 * 1000000) = 164.832
Description:
(SMS+WAP)*(Push Information + Pull Information + Synchronize On Demand) * (Android Mobile) *

(Facebook + Twitter) * (Farmville + Twitter Followers) / (Living on the Net * Pro Active)
For Privacy Score 164.832, Consumer Privacy Level equals 1 = High PLM Intrusion
Following tables are representing possible examples of Privacy Points (Constants used for Privacy Score
Calculation):
39 | P a g e
October2010
Device Capability Definition Privacy Points
Push Information Push Subscribed Information to Device +10
Pull Information Pull Consumer Private Information from Device +5
Synchronize on Demand Automatic Synchronization of Private Information +1
Device Category Definition Privacy Points

Android Mobile Open Source mobile phone with enabled 2.0 +80
iPad Vendor agnostic Tablet with enabled Web 2.0 and +100
mobility capabilities
Netbook Mini Laptop with any Operating System +120
Information Channel Definition Privacy Points

SMS Short Message Service +500
WAP Wireless Application Protocol +10
IVR Incoming Voice Recognition +1
Business Service Definition Privacy Points

Facebook Notifications and Alerts from Facebook +1000
Twitter Messages from Twitter +1500
LinkedIn Messages and Invitations from LinkedIn +100
Business Category Definition Privacy Points

Farmville Messages from Farmville +10
Twitter Followers Messages from Twitter Followers +1000
Amazon Marketing Amazon Marketing Channels +100
User Agility Definition Privacy Points

Living on the Net More than 8 hours a day connected to Internet with at +100000
least one device
Business User Only Usage of Business/Corporate device during business +10000
hours only
Occasional User Less than 1 hour a day connected to Internet with at +1000
least one device
Privacy Config. Level Definition Privacy Points

Inactive Inbound Communication is disabled 0
Passive Read Only, Notifications are disabled +100
Active Active Communication through one or more devices +100000
Pro Active Pro Active Communication +1000000
40 | P a g e
October2010
Absolute Multi-tenancy or The story about Massive Computing.

Multi-tenancy in cloud means sharing of resources (such as computing, networking, storage) and
services for multiple consumers and client organizations (tenants).
Let’s think about it. Speaking pure economically, a cloud provider is able to minimize the infrastructure
and labor costs as well as spread them across all customers with similar needs. Total Cost of Ownership
is certainly well known business driver and indicates great interest of all business stakeholders looking
forward to receive services for free. Well, this is possible today only on certain level and with limited
elasticity. The reason is shockingly very simple: We don’t have platform which will enable dynamic
sharing and isolation on all levels of XaaS stack.
Chris Anderson, author of the book “Free – The Future of a radical price”, defined ten principles of
“Abundance Thinking”. First principle is “If it’s digital, sooner or later it’s going to be free…” If this is the
case, then absolute Multi-tenancy is inevitable.
Anyway, what’s the history of multi-tenant architectures? We can start with well-known Mainframes
which shared quite a lot considering that particular time. What about P2P networks or science projects
(SETI@HOME) running on computers and game consoles (Playstation3)? Or even Botnets? Distributed
Computing and Grid Computing were certainly pioneers with open protocols and atomized units sharing
computing power, storage and network.
So, maximal sharing on all levels means absolute multi-tenancy, something we didn’t invite yet and it’s
far more complicated than specification of various Multi-tenancy models. We believe this is a key to
Massive Computing without boundaries, running inside Cloud Computing and utilizing Stream
Computing. Elementary model of basic components is depicted in (Figure 34: Massive Computing – Elementary
Model).
Figure 34: Massive Computing – Elementary Model
These are potential Massive Computing Characteristics:
41 | P a g e
October2010
 Code is Everywhere – Same code (on logical level) runs everywhere serving as a foundation
platform for services running above
 It’s Replicable – Creates Virtual Environment from Image at any location and act as Independent,
Atomized unit
 It’s Adaptable – Uses Open API with dynamic specification
 Supports Service Abstraction and Recursion abilities
 Content is Unique (de-duplication) and identified by distributed metadata repositories
 Semantic standardization – metadata are semantic enabled
 Each Atomized Unit runs Autonomously and depends only on Task prioritization
 Push and Pull Methods based on Service Subscription
 Unit Services represents various XaaS encapsulated components
 Service Logic has various levels based on XaaS Service
We are fully aware about inexistency of Massive Computing today, but we really believe this is the
golden key to absolute multi-tenant model. Perhaps our Multi-tenancy reference model (Figure 35: Multi-
tenancy reference Model) can help (at least for now) to recognize our options for today and open doors for
tomorrow.
Figure 35: Multi-tenancy reference Model
42 | P a g e
October2010
XaaS reference Model and Multi-tenancy reference Model

The ICF Multi-tenancy reference model offers great combination of sharing and isolation at all XaaS
levels (vertically) and building blocks (horizontally). The reference model consists from XaaS category
connected to particular Shared Level and associated with particular Multi-tenant model and Isolation
Level. A combined Shared and Isolation level characterizes Multi-tenancy level (Figure 36: Multi-tenancy
Score Levels) for each XaaS Component. Let’s take a look at the Score Overview below:
Figure 36: Multi-tenancy Score Levels
43 | P a g e
October2010
Description of Multi-tenant Models:
1. Physical Models covers DCaaS and IaaS

a. DcaaS Model represents Physical structure of Data Center with following inputs:
 Security – Building and Departments Security Management
 Governance – DC Operations Management
 Network – Main Dedicated Connection (Telco Provider)
 Utilities:
1. Power – Energy for Building Operations and Computing
2. Water for Building Operations, AC and Computing cooling Systems
3. Air for Building Operations, AC and Computing cooling Systems
 People – DC Staff Residing in Building Office
Figure 37: DCaaS Multi-tenancy Model
Multi-tenancy description for DC Building blocks:

 Bandwidth Meters (Management) – Shared for all connections
 Utilities Meters (Management) – Shared for all utilities
 Offices (Operation Management) – Shared for all Operations and Customers
 Fire Suppression Systems (Management) – Shared for all locations
 UPS + Generator (Backup Management) – Shared for all Systems
 Air Conditioning (Temperature Management) – Shared for all locations
 Access Management - Shared on Building Level, Isolated on Location and
Customer Levels
44 | P a g e
October2010
b. IaaS Model represents Physical structure of Deployed Infrastructure with following
inputs:
 Security – Physical Infrastructure Security (Rack)
 Governance – Management of Infrastructure Deployment, Upgrades etc.
 Network – Limited Connection/Bandwidth based on SLA
 Power for Infrastructure Components within Rack
Figure 38: IaaS Multi-tenancy Model
Multi-tenancy description for Infrastructure Building blocks:

 Network Switch – Shared for Rack Components, Isolated per Network or
Customer
 LAN – Shared, Isolated per Customer
 WAN – Shared
 Wi-Fi – Shared among Customers within DC Facility
 Fibre Channel - Shared
 Storage Switch – Shared , Isolated for HA Configurations
 SAN – Shared, Isolated for HA Configurations
 RAID – Isolated on Customer / Array Level
 DAS – Shared, Isolated for HA Configurations
 NAS – Shared, Isolated for HA Configurations
 Server – Shared, Isolated per Customer
 Server Bus, Cache – Shared
 Server Storage and Network Interfaces – Shared , Isolated per Customer
 CPU – Isolated per Customer
 Memory – Shared on CPU level, Isolated per Customer
45 | P a g e
October2010
2. Software Models covers PaaS and Seas:
a. PaaS Model represents Software and Platform Foundation with following inputs:
 Security – Security Management of Platforms
 Governance – Platform Management
 Network – Software Networks
 Data – Platform related Data
 Users – Platform Users
Figure 39: PaaS Multi-tenancy Model
Multi-tenancy description for Platform Building blocks:
 Virtualization – Shared, isolated per customer, channel, virtual machine, network

 OS – Shared, isolated per customer, virtual machine
 File System – Shared, isolated per virtual machine, customer
 Secure Protocol – Isolated per virtual machine, customer
 Insecure Protocol – Shared
 Internet – Shared
 Extranet, Intranet, VPN – Isolated per customer
 DMZ – Shared, Isolated per customer
 Infrastructure Platforms – Fully Shared, Isolated per customer
 Java – Shared on System level, isolated per customer and virtual machine
 Cocoa - Shared on System level, isolated per customer and virtual machine
 Flash / Flex – Shared on System level, isolated per customer and virtual machine
 .Net - Shared on System level, isolated per customer and virtual machine
 Other Application Platforms – Shared on Various levels , isolated per customer and
virtual machine
46 | P a g e
October2010
b. SaaS Model represents Software with following inputs:
 Security – Software Security Management
 Governance – Software Management
 Network – Software Networks
 Data – Software related Data
 Users – Software Users
Figure 40: SaaS Multi-tenancy Model
Multi-tenancy description for Software Building blocks:
 Wikis, Blogs – Fully Shared

 Messaging – Shared , Isolated per customer, domain, channel
 File Sharing – Isolated per Customer
 Video Conference – Shared , Isolated for HA and Governance Solutions
 WEB – Shared , Isolated for HA and Governance Solutions
 Portal, Reporting, Channels – Shared, Isolated per Customer and for HA /
Governance Solutions
 CMS – Fully Isolated
 Infrastructure, Security, Business Management - Fully Isolated per customer
 Intrusion – Isolated per customer, channel
 Encryption – Fully Shared
 Business Intelligence, Packaged App – Shared, Isolated per customer
 Database, Data warehouse- Isolated per customer
 Perimeter – Shared, Isolated per customer and network
 Anti-X – Fully Shared
 SOA, Processing – Shared, Isolated per Customer
 Communication – Shared, Isolated per Customer, Channel, Network
47 | P a g e
October2010
3. Data Model
a. DaaS Model represents Structured and Unstructured Data with following inputs:
 Security – Data Security
 Governance – Data Management
 Data:
1. Information - files and streams
2. Video – files and streams
3. Audio – files and streams
 Users – Data Users
Figure 41: DaaS Multi-tenancy Model
Multi-tenancy description for Data Building blocks:
 Audio, Video, Pictures, Binary, Unstructured Files, Structured Files, Information

Streams – Shared, Isolated per Customer, Network, Channel
 Alerts – Isolated per Customer, Network, Channel
 Instant and Unified Messaging – Isolated per Customer, Network, Channel
 Logs, Security Info - Isolated per Customer, Network, Channel, Business Segment,
Domain, Application
 Database – Shared on Schema Level, Isolated per Customer, Application
 Repository – Shared per Domain, Isolated per Segment, Application
 Metadata – Isolated per Customer
48 | P a g e
October2010
4. Business Models covers BPaaS, INaaS and BaaS
a. BPaaS represents Business Processes with following inputs:
 Security – Business Process Security
 Governance – Business Process Management
 Data – Business Process related Data
 Actors – Business Process Actors
 Processes – Business Processes
Figure 42: BPaaS Multi-tenancy Model
Multi-tenancy description for Business Process Building blocks:
 Capabilities – are fully shared among all processes

 Scenarios, Tasks, Processes, Use Cases – Shared, Isolated per Customer
 Actors – are fully shared among all processes
 Process Lifecycle, Process Map, Relationships, Time – Shared, Isolated per Customer
 Business Rules – Shared, Isolated per Customer
 Change Management, Re/Source Management, Performance Management –
Shared, Isolated per Customer
 Schedule – Shared, Isolated per Customer
 Initiation Phase – Fully Shared
 Modeling, Deployment, Termination Phase – Isolated per Customer
 Simulation – Shared , Isolated per Customer
 Future, Present, Past Views – Isolated per Customer
49 | P a g e
October2010
b. INaaS – represents Industry Services with following inputs:
 Security – Industry Services Security
 Governance – Industry Services Management
 Data – Industry related Data
 Actors – Industry Actors
 Processes – Industry Processes
Figure 43: INaaS Multi-tenancy Model
INaaS Model is great example of absolute sharing. It shares everything to everybody. It’s totally open in
order to support business services and business processes. Industry networks are very similar to social
networks – both are collaborative, the only difference is that industry networks are created by
categorized business services , social networks are public or represents private communities.
50 | P a g e
October2010
c. BaaS – represents Business Services with following inputs:
 Security – Business Service Security
 Governance – Business Service Management
 Data – Business Information
 Actors – Business Actors
 Processes – Business Processes
Figure 44: BaaS Multi-tenancy Model
Multi-tenancy description for Business Building blocks:
 Service Management, Business Constraints – Shared, Isolated per Customer

 Business Variables – Isolated per Customer (Business setup and differentiators)
 Business Status – Shared
 Business Vision, Business Strategy, Business Goal, Business Model, Business Tactic,
Business Objective, Business Lifecycle, Business Principals, Business (Architecture)
Differentiators – Shared, Isolated per Customer
 Industry Type, Business Domain – Publicly shared for propagation and mediation
purposes
51 | P a g e
October2010
Multi-tenancy Isolation Spheres

Based on ICF Multi-tenancy reference models, we identified major Isolation Spheres, which are depicted
below:
Figure 45: Multi-Tenancy Isolation Spheres
Cloud Business Environment Encapsulation

Taxonomy from different Cloud reference Architecture almost always starts with cloud types, such as
Private, Public Hybrid etc., but for cloud business standpoint it’s not that relevant as classification into
business, industry and social clouds (networks) and their target environments with Multi-tenant and
security characteristics as major driving factors. Encapsulation and Orchestration of these Environments
and Services inside them is visible and maintained by Environment Owners and Integration Providers
only.
Figure 46: Deployment & Orchestration Example
The Diagram above shows simple example of Environment and Service Deployment, Orchestration and
Encapsulation inside various clouds and their integration.
52 | P a g e
October2010
How Cloud reshaped Data Center Architecture

The Date Center as we knew it before Cloud era, supported (from Business Perspective) following
services:
 MSP, ASP , ISP

 Web Hosting
 CDN
 Network Provider
New Business Requirements and XaaS model reshaped existing and new Datacenters into following
supported services:
 Cloud Provider
 CDN
 Network Provider
 Mobile Carrier
 Carrier Ethernet Provider
 Storage Services
 Internet & Ethernet Exchange
 MSO / Cable Provider
 Customers – DCaaS / IaaS /SaaS
 Carrier Ethernet Provider
All changes are related to New Services, mostly monetized from Enterprise Infrastructure Area with
enhanced specialization driven by new technologies.
Figure 47: Data Center Container
We can also see changes reshaping Data Center baseline such as
 Shared Data Center Facilities (DCaaS)

 New Building Designs in order to offer better component granularity and additional security
levels
 Data Center Containers supporting collocation environment – Migration capability enabler for
DCaaS
53 | P a g e
October2010
Cloud Business Symbols

As an Essential part of Cloud Business Architecture, we recognized importance of Cloud Business
Symbols standardization. Cloud Business Symbols should help to create transparent, coherent and
aligned notation of CBA (developed by Open Group).
Figure 48: Cloud Business Symbols
54 | P a g e
October2010
Conclusion
The ICF represents new dimension in Enterprise Architecture, adding dynamic factor into static
structures and is dedicated to completion of cloud, enterprise and solution frameworks.
The ICF’s core structure is composited from three Levels, six Domains, numerous Silos and their
Elements. The Framework itself doesn’t represent all possible elements. We believe in iterative process
and continuous evolution of existing terms and dynamic structures, progressively changing behavior and
functionality of specified building blocks and deliverables.
The ICF Framework, at the top of the Component Structures, collects and holds all Cloud related objects
and refers to relevant methods and calculations for Service Configuration, Status Map and Service
utilization prediction. All Input / output values are measurable and configurable within related Time
Frame – general variable which has 3 time zones (past, present, future).
The ICF is “Open” Cloud Framework, or in other words it’s open to cooperation/reference from/to any
domain/level/segment oriented frameworks such as Jericho Forum Security Cube for Cloud, Cloud
Buying Lifecycle (Open Group) etc.
Figure 49: The ICF Cloud Machine
55 | P a g e
October2010
Table of Figures
Figure 1: Cloud Collaboration Model ............................................................................................................ 4
Figure 2: Business Service Orchestration ...................................................................................................... 5
Figure 3: Computing Evolution ...................................................................................................................... 6
Figure 4: Computing Architectures ............................................................................................................... 7
Figure 5: Cloud Components and Enterprise Framework ............................................................................. 8
Figure 6: Dynamic and Static Frameworks – The Great Symbiosis .............................................................. 9
Figure 7: Who should use ICF and Why ...................................................................................................... 10
Figure 8: The Integrated Cloud Framework ................................................................................................ 11
Figure 9: The ICF - XaaS Component Re/Sources ........................................................................................ 12
Figure 10: ICF Models and Views ................................................................................................................ 14
Figure 11: Providers and Services Model .................................................................................................... 15
Figure 12: The XaaS Service Category definitions and Examples ................................................................ 16
Figure 13: Cloud Business Ecosystem View ................................................................................................. 18
Figure 14: Activity deliverables ................................................................................................................... 19
Figure 15: Cloud Business Service Offer Lifecycle ........................................................................................ 20
Figure 16: Cloud Buying Lifecycle ................................................................................................................ 21
Figure 17: Cloud Business Search Lifecycle ................................................................................................. 22
Figure 18: Cloud Business Mediation Lifecycle............................................................................................ 23
Figure 19: Cloud Service Design Lifecycle .................................................................................................... 24
Figure 20: Cloud Business Mashup Lifecycle ............................................................................................... 25
Figure 21: Cloud Service Orchestration Lifecycle ........................................................................................ 26
Figure 22: Cloud Service Orchestration Decomposition- Inside The Service CUBE...................................... 27
Figure 23: Cloud Service Orchestration Decomposition- Outside the Service CUBE ................................... 28
Figure 24: Cloud Catalogs ........................................................................................................................... 29
Figure 25: The Component Catalog............................................................................................................. 30
Figure 26: Cloud Business Service Catalog – Business Segmentation ......................................................... 31
Figure 27: Cloud Business Catalog – Industry Segmentation, parameters, Management and Status ....... 32
Figure 28: Cloud Component Catalog Example – INaaS point of view........................................................ 33
Figure 29: Service Measurement Index - Characteristics ............................................................................ 34
Figure 30: Service Measurement Index – Characteristics ........................................................................... 36
Figure 31: Cloud Security – Cube Dimensions specified by Jericho Forum .................................................. 37
Figure 32: Cloud Business Security Layers View .......................................................................................... 38
Figure 33: PLM – Consumer Privacy Intrusion Level identified by Privacy Score ........................................ 39
Figure 34: Massive Computing – Elementary Model .................................................................................. 41
Figure 35: Multi-tenancy reference Model ................................................................................................. 42
Figure 36: Multi-tenancy Score Levels ........................................................................................................ 43
Figure 37: DCaaS Multi-tenancy Model ...................................................................................................... 44
Figure 38: IaaS Multi-tenancy Model .......................................................................................................... 45
Figure 39: PaaS Multi-tenancy Model ......................................................................................................... 46
Figure 40: SaaS Multi-tenancy Model ......................................................................................................... 47
56 | P a g e
October2010
Figure 41: DaaS Multi-tenancy Model ........................................................................................................ 48
Figure 42: BPaaS Multi-tenancy Model ...................................................................................................... 49
Figure 43: INaaS Multi-tenancy Model ....................................................................................................... 50
Figure 44: BaaS Multi-tenancy Model......................................................................................................... 51
Figure 45: Multi-Tenancy Isolation Spheres ............................................................................................... 52
Figure 46: Deployment & Orchestration Example ...................................................................................... 52
Figure 47: Data Center Container ............................................................................................................... 53
Figure 48: Cloud Business Symbols ............................................................................................................. 54
Figure 49: The ICF Cloud Machine .............................................................................................................. 55
57 | P a g e
October2010
Acronym Key and Glossary Terms

Keys and Terms Definition
X Computing Represents “Computing” related terms such as “Cloud”, “Stream”, “Grid” ,
similarly to XaaS (X as a Service)
Stream Computing Real-time, adaptive processing of enormous volumes of continuously
streaming data — both structured and unstructured
http://public.dhe.ibm.com/software/data/sw-
library/ii/whitepaper/SystemS_2008-1001.pdf
Distributed Computing Computing that involves multiple computers remote from each other that
each has a role in a computation problem or information processing.
http://distributedcomputing.info/devel.html
Grid Computing Grids are a form of distributed computing whereby a “super virtual computer”
is composed of many networked loosely coupled computers acting together
to perform very large tasks.
http://en.wikipedia.org/wiki/Grid_computing
Massive Computing Ultimate computing system concentrate above absolute Multi-tenant model ,
running in Cloud and utilizing Stream Computing.
Augmented Reality Live direct or indirect view of a physical real-world environment whose
elements are augmented by virtual computer-generated imagery
CBA Cloud Business Architecture
WOA Web Oriented Architecture
http://hinchcliffe.org/archive/2009/06/06/16901.aspx
http://hinchcliffe.org/archive/2008/02/27/16617.aspx
ROA Resource Oriented Architecture
http://en.wikipedia.org/wiki/Resource_oriented_architecture
Cloud 2.0 Advanced level of Cloud Computing (2.0 as in Web 2.0)
http://cloud-computing.learningtree.com/2010/05/24/cloud-2-0-the-rapid-
evolution-of-the-cloud/
ICF Integrated Cloud Framework
ICF Levels Levels shows architecture areas distributed in vertical hierarchy and contains
high level architecture deliverables
ICF Domains Domains separates architecture areas into logical blocks and contains
abstracts
ICF Abstracts Abstracts holds elements and are owned by domains
ICF Elements Elements are basic building blocks situated inside abstracts
SOA Service Oriented Architecture
EOA Enterprise Oriented Architecture
RIA Rich Internet Application Architecture
QOS Quality of Service
CCSDL Cloud Component Service Definition Language – XML based language
AOP Architectures of Participation
PLM Privacy Level Meter
SLA Service Level Agreement
Cloud Bursting Cloud bursting is the practice of “bursting” into a cloud when capacity has
been reached in the corporate cloud/data center.
Anti-X Security - Antivirus, AntiSpam, AntiSpyware, AntiMalwares, etc.
58 | P a g e
October2010
References
[1] DION HINCHCLIFFE : HOW THE WEB OS HAS BEGUN TO RESHAPE IT AND BUSINESS, 09/2009
[2] ERIK BRYNJOLFSSON, MICHAEL SCHRAGE: THE NEW, FASTER FACE OF INNOVATION, 08/2009
[3] MARK SKILTON, VLADIMIR BARANEK; CAPGEMINI: CLOUD BUSINESS ARCHITECTURE NOTATION – THE
OPEN GROUP, 09/2010
[4] MARK SKILTON; CAPGEMINI: BUILDING RETURN ON INVESTMENT FROM CLOUD COMPUTING, 04/2010
[5] JERICHO FORUM ; OPEN GROUP: CLOUD CUBE MODEL - SELECTING CLOUD FORMATIONS FOR SECURE
COLLABORATION, 04/2009
[6] NICOLE A. OZER, CHRIS CONLEY; DEMAND YOUR DOT RIGHTS: CLOUD COMPUTING : STORM WARNING
FOR PRIVACY , 01/2010
[7] MARK SKILTON, THEO ELZINGA, VLADIMIR BARANEK; CAPGEMINI: TOWARDS A BUSINESS USER DRIVEN
VIEW OF C LOUD C OMPUTING , 08/2010
[8] PENELOPE GORDON, THE OPEN GROUP: CLOUD BUYING LIFECYCLE, 08/2010
[9] DION HINCHCLIFFE : UNBOXING WEB-ORIENTED ARCHITECTURE - THE 6 ASPECTS OF AN EMERGENT
ARCHITECTURAL STYLE, 06/2009
[10] CHRIS CZARNECKI: CLOUD 2.0 - THE RAPID EVOLUTION OF THE CLOUD, 05/2010
[11] DAVID BANKS, JOHN E RICKSON, MICHAEL RHODES ; HP: MULTI-TENANCY IN CLOUD-BASED
COLLABORATION SERVICES, 02/2009
[12] YEFIM V. NATIS, ERIC KNIPP; GARTNER: GARTNER REFERENCE ARCHITECTURE FOR MULTITENANCY,
08/2010
[13] ALLAN SIEGERT ; HP: MULTITENANCY : THE NEXT CLOUD COMPUTING WAVE, 05/2010
[14] CHRIS ANDERSON : FREE – THE FUTURE OF A RADICAL PRICE , ISBN 978-1-4013-2290-8
[15] NIST: THE NIST DEFINITION OF CLOUD COMPUTING V15, 07/2009
[16] RINAT ABDULLIN : CLOUD BURSTING SCENARIOS FOR SMALL COMPANIES, 06/2009
[17] CARNEGIE MELLON; SMI CONSORTIUM : CARNEGIE MELLON SILICON VALLEY RESEARCHERS
COLLABORATE WITH INDUSTRY TO DEVELOP MEASURES OF QUALITY AND PERFORMANCE FOR CLOUD-
COMPUTING SERVICES , 05/2010
[18] RYAN CARSON; CARSONIFIED : HOW TO TRACK SIX KEY METRICS FOR YOUR WEB APP, 09/2010
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or
transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise,
without the prior permission of the copyright owners.
59 | P a g e

ICF - The Framework For Cloud Business Revolution - v1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ICF - The Framework For Cloud Business Revolution - v1

Uploaded by

Copyright:

Available Formats

The ICF Whitepaper, Version 1.

Cloud Business Collaboration - New Business Opportunities

We started with emails as a basic element of

We certainly realized changes which leaded to

Especially the last keyword “Agility” is connected

Figure 1: Cloud Collaboration Model

Cloud Business Service – SOA included, WOA presented, EOA enabled

Figure 2: Business Service Orchestration

Computing Evolution or How did we get here

Figure 3: Computing Evolution

Figure 4: Computing Architectures

Why do we need Cloud Framework?

Figure 5: Cloud Components and Enterprise Framework

The ICF vs. Enterprise Architecture – the Great Symbiosis

ICF Cloud Actors

IAF Cora Togaf

SAP IBM Microsoft

Legend: Cloud Framework Enterprise Framework Solution Framework

Figure 6: Dynamic and Static Frameworks – The Great Symbiosis

Who should use ICF and why?

Figure 7: Who should use ICF and Why

The Integrated Cloud Framework (ICF)

Figure 8: The Integrated Cloud Framework

The ICF Component Re/Sources

1. SET – to Configure Particular Component or Cloud Business Service (Orchestrated)

Figure 9: The ICF - XaaS Component Re/Sources

The ICF Deliverable Documents

ICF Models and Views

Figure 10: ICF Models and Views

Providers and Services – Foundation of the ICF

Figure 11: Providers and Services Model

Figure 12: The XaaS Service Category definitions and Examples

Cloud Essentials - Characteristics

Cloud Business Ecosystem

Figure 13: Cloud Business Ecosystem View

Activities & Actors – Collection of lifecycles:

1. Develop – Service Developer develops Cloud Service

1. Business Service – is developed by Developer, delivered by Service Provider, integrated by

Figure 14: Activity deliverables

Cloud Business Service Offer Lifecycle

Figure 15: Cloud Business Service Offer Lifecycle

Cloud Buying Lifecycle

Figure 16: Cloud Buying Lifecycle

Cloud Buying Phases are described as:

 “Determine Fit”: determine if buyer’s objectives and seller’s capabilities align

Deliverables ( Highlighted ), categorized by Phase, shows complexity of buying process and

Cloud Business Search Lifecycle

1. Internal Cloud Business Catalog

Figure 17: Cloud Business Search Lifecycle

Cloud Business Mediation Lifecycle

Figure 18: Cloud Business Mediation Lifecycle

Cloud Service Design Lifecycle

Figure 19: Cloud Service Design Lifecycle

Cloud Business Mashup Lifecycle

Figure 20: Cloud Business Mashup Lifecycle

As in traditional Development methodologies, product is tested in various environments (UAT,FAT etc.)

Cloud Service Orchestration Lifecycle

Figure 21: Cloud Service Orchestration Lifecycle

As in traditional Development methodologies, product is tested in various environments (UAT,FAT etc.)

Cloud Catalog – The Cloud Business Proposal

 Publishing / Mediation of Cloud Services

We recognized three major Catalog types specified below.

Figure 24: Cloud Catalogs

(510168025001010) = 1648320000000 / (100000 * 1000000) = 164.832

(SMS+WAP)(Push Information + Pull Information + Synchronize On Demand) (Android Mobile) *