next generation management for adaptive environments manfi 2010 keynote - joel_fleck.pdf ·...

Next Generation Management Next Generation Management

for Adaptive Environmentsfor Adaptive Environments

ManFIManFI 2010 Keynote2010 Keynote

Osaka JapanOsaka Japan19 April, 19 April,

20102010

l l kl l kJoel J. Fleck IIJoel J. Fleck IIHewlettHewlett-- PackardPackard

Office Office of Strategy & of Strategy & TechnologyTechnologygygy gygyHP Software and Solutions CTO OfficeHP Software and Solutions CTO Office

[email protected]@hp.com

Outline

• Background and Challengesg g• Domains• Domain Relationshipsp• Relationship Management• ConclusionsCo c us o s

page 219-Apr-10 - jjf2 ManFI - NOMS 2010

A Couple of Thoughts

No matter how adaptive/autonomic your application (and the network it runs on) is, it is still basically a static application unless:application unless:

• The network description used for management has been extended beyond the static semantic description of its y pcomposing elements,

• Your stimuli generation, analytic and decision/action system(s) d t ith th t it l ti d li ti adapt with the system as its solutions and applications

reconfigure,• The relationships between the domains composing the The relationships between the domains composing the

applications are dynamically managed.

19-Apr-10 - jjf2 page 3ManFI - NOMS 2010

Next Generation Management

• Put another way:y

The old way (legacy and current) of static, reactive y ( g y ) ,management won’t work in a highly distributed, multi-provider, multi-app environment. A new adaptable, pro-

ti t hit t t th t active management architecture must emerge that emphasizes management strategies for the “space between” connecting apps providers users and between connecting apps, providers, users and domains.


Management Challenges for Adaptive Communications EnvironmentsCommunications Environments• New Communications Environments will be role-based and highly

distributeddistributed,• Much more emphasis on current or future role/task (what is or will

be happening) in management decisions/actions rather than past ( h h h d)(what has happened),

• Rather than slow and re-active (respond after-the-fact to undesireable events) mode, need to move to a fast and pro-active mode events) mode, need to move to a fast and pro active mode (reduce/prevent undesireable events),

• Ability to adapt to unknown elements (environmental, hardware and ftw ) i ti th tsoftware) impacting the system,

• Understand the relationships of distributed Domains:– Hierarchical relationshipsHierarchical relationships– Peer-to-peer relationships

• Need to manage the “space between” distributed Domains.


Current vs Next Generation Management

• Current:– End-to-end process based– Very large monolithic, static analysis systems– Reactive “limit damage once a bad event has occurred”– Reactive, limit damage once a bad event has occurred– Primary emphasis is on the management of the networki.e., the management environment reflects the traditional service delivery

i tenvironment

Future:– Domain, Relationship focused, policy-based– Adaptive collections of analytic components tailored to the triggering

stimuli and contextstimuli and context– Both reactive and pro-active, “reduce probability of bad events”– 3 Levels of Management focus: Local (intra-Domain), Relationship

(b t 2 D i ) d S i ( D i )(between 2 Domains) and Service (among many Domains)– Mission is to satisfy goals of system rather than follow a “process”


Process Based Management (Current) vs. Adaptive Policy-Based Process ManagementAdaptive Policy-Based Process Management• Process Based Management:

F d f d d h h ( ll ) – Focus on static descriptions of end-to-end processes which (typically) span many domains and scopes of authority

– Top-down de-compositional approachp p pp– Rarely changes (either triggering events, analytics or even decision

support)

• Adaptive Policy-Based Process Management:– Driven by Business Goals/Rules, Ontologies and Policies that describe

the both intra and inter domain relationshipsthe both intra and inter-domain relationships– Context-aware– Balance of Structured (but adaptable) internal domain processes and

d d h d h hl d lun-Structured (ad hoc and highly adaptive) external processes– Control loops between and within domains provide feed-back and feed-

forward among both peer-to-peer and hierarchical relationshipsg p p p– Set of adaptive peer-to-peer relationships between Stimuli Generation,

Analytics and Decision/Action rather than monolithic silopage 719-Apr-10 - jjf2 ManFI - NOMS 2010

Outline



Characteristics of Adaptive Management

• Declarative (Goal-based) rather than procedural (Process-( ) p (based),

• Domains defined by scope-of-authority of Role rather than bit “ d h ” d iarbitrary or “ad-hoc” domains,

• Adaptability both intra-domain and inter-domain on peer-to-peer (horizontal) and vertical (top-down and bottom-up),peer (horizontal) and vertical (top down and bottom up),

• Requires better modeling of environment “between the domains”,

• Requires an ontological understanding of relationships between domains,R i d i bilit t t / dif /d l t • Requires dynamic ability to create/modify/delete Relationships between domains,

• Process model within Role-based domainsProcess model within Role based domains,• Is Context-aware.


What is an Adaptive Environment Domain?

• Boundaries dictated by the scope of authority of the role of the Domain; l f h d h i.e., any policy governing a resource or artifact that is outside the scope

of authority of the role of the Domain is external to the Domain (i.e., it’s in another Domain or is governing an Relationship between Domains),

f l l• Contains a set of Internal Goals,• Contains a set of Internal Policies,• May have External Goals and Policies (which govern relationships with May have External Goals and Policies (which govern relationships with

other Domains),• May expose capabilities (Contracts) and data (via Contracts),• Exposed capabilities (and data) are governed by External Goals and • Exposed capabilities (and data) are governed by External Goals and

Policies,• External Goals and Policies must be consistent with Internal Goals and

P li iPolicies,• Processes must be contained within Domain (cannot span two or more

scope of authorities).


Adaptive Domain Structure

One Export/Import Pair per Relationship

RelationshipExport

Artifacts

RelationshipImport

Artifacts

DomainDomainDomainDomain

(scope of Authority of Role)(scope of Authority of Role)InternalPolicies


Additional Characteristics of a Domain

• All External Goals of a Domain must be consistent with the Internal Goals f h Dof the Domain,

• All External Policies exposed by a Domain must be consistent with the Internal Policies of the Domain,

• A Domain must be wholly contained within one horizontal layer (Tier),• A Domain must be wholly contained within one vertical slice (Concern),• A Domain may contain both Explicit (Documented) and Tacit (un• A Domain may contain both Explicit (Documented) and Tacit (un-

Documented) Policies,• Two Domains interact via a Relationship,

R l i hi b i h hi hi l • Relationships may be either hierarchical or peer-to-peer,• For each Relationship of which the Domain is a member, there exists a

layered Domain Relationship Map which describes the Domain’s f h l hperspective of the Relationship,

• Each Domain Relationship Map is described by an Ontology which captures the relationships and semantics of the Map.p p p


Managing “The Space Between”

• The problem is not how to manage the domains, but p g ,rather the space between (i.e., the relationship between domains),

d h h d d h h d h f– To do this we have to understand the “what and why” of software artifacts each side of the relationship:• Ontology of software artifacts• Ontology of software artifacts• Goals• Policies• Policies• Actions• Data• Data


Outline



What is an Inter-Domain Relationship?

• Sharing of capabilities and/or data between two g p /domains:

– Peer-to-peer relationship between domains (Federation),

– Hierarchical relationship between domains (Composition).


Characteristics of Inter-Domain Relationships

Current FutureCurrent FutureStatic Dynamic

S l d d (f l h d C d “b l ” f R l h M d l Specialized code (frequently hand-crafted) implementing ‘one-of’ interfaces

Code “built” from Relationship Model (i.e., derived from Business Rules that define reasons for Domain

ti i ti )participation)Require large amounts of resources to build and test

Model-driven approach to building and testing reducing handcrafting and testing

Frequently poorly documented Largely self-documented through Relationship Modelp

“One-of” nature requires significant management effort of each interface

Management by monitoring Relationship rather than specific interfaces


interfacesInflexible Flexible

Inter-Domain Relationships

Concern 1 Concern 2One Export/Import Pair per Association

Tier 1

AssociationExport

Artifacts

AssociationImport

Artifacts

Domain

(scope of Authority of Role)InternalPolicies

One Export/Import Pair per Association

AssociationExport

Artifacts


AssociationImport

Artifacts

Domain


Tier 2

AssociationExport

Artifacts

AssociationImport

Artifacts

Domain


AssociationExport

Artifacts


AssociationImport

Artifacts

Domain


AssociationExport

Artifacts


AssociationImport

Artifacts

Domain


Tier 3

AssociationExport

Artifacts


AssociationImport

Artifacts

Domain


AssociationExport

Artifacts


AssociationImport

Artifacts

Domain


AssociationExport

Artifacts


AssociationImport

Artifacts

Domain



Characteristics of a Peer-to-Peer Domain RelationshipsRelationships

• Peer-to-Peer (Federations):( )– Are 1 Domain (peer) to 1 Domain (peer),– Each constituent Domain must be a member of the same Tier,

Domain Federations may span Concerns– Domain Federations may span Concerns,– Each constituent Domain provides two groups of Policies that

govern the Federation from the perspective of the constituent Domain: a set Export Policies and a set of Import Policies Each Domain: a set Export Policies and a set of Import Policies. Each group is visible to the Federation,

– The Export/Import pairs for each member of the Federation must be compatible with the other members Import/Export pairbe compatible with the other members Import/Export pair,

– The Federation Export and Import Policies must be consistent with the Internal Policies of the Domain.


Characteristics of Hierarchical Domain RelationshipsRelationships

• Hierarchical Domain Relationships (Compositions):p ( p )– Are 1 Domain (higher level) to 1 or more Domains (lower level),– Each Composition constituent Domain must be consistent with

upper/lower membersupper/lower members,– Domain Compositions may span two Tiers,– Domain Compositions may be within a single Tier,

E h tit t D i id t f P li i th t – Each constituent Domain provides two groups of Policies that govern the Composition from the perspective of the constituent Domain: a set Export Policies and a set of Import Policies. Each group is visible to the Compositiongroup is visible to the Composition,

– The Composition Export and Import Policies must be consistent with the Internal Policies of the Domain.


Adaptive Domain with Federation and CompositionComposition

One Export/Import Pair per Composition

CompositionExport

Artifacts

One Ex

CompositionImport

Artifacts

FederationExport

Artifacts

xport/ImporDomainDomain

FederationImport

Artifacts

rt Pair per F

DomainDomain

(scope of Authority of Role)(scope of Authority of Role)Artifacts Federation

Domain BusinessStrategy, Goals and Policies


Inter-Domain Relationships

Concern 1 Concern 2

CompatibleTier 1 Compatible

Tier 2 Compatible

Tier 3 Compatible

Consistent Consistent


Domain Business Strategy, Goals and Rules

RConsistent with

OutgoingOutgoingRelationshipRelationship

SS

Out

Relationsh

DomainDomainlogy

S b t f

•• StrategyStrategy

•• GoalsGoals

•• RulesRules

tgoing

hip Ontolo

•• Business StrategyBusiness Strategy

•• Business GoalsBusiness GoalsI iI i

Relmain Ontol Subset of

and consistent

with

RulesRules ogy

•• Business RulesBusiness RulesIncomingIncoming

RelationshipRelationship

•• StrategyStrategy

Incom

ationshipDom

with

•• GoalsGoals

•• RulesRules

ming

p Ontology


y

Consistent with

Inter-Domain Relationship Map

Domain Ontology

OWL 2.0

Subset of d

Inter‐Domain Relationship Map

Relationship Ontology

Owl 2.0

and consistent

with

SBVR Business Rules

SBVR Vocabulary• noun concepts

Consistent with

• fact types

SBVR Rules

Technology Neutral Policy Representations

Transformations


N3

Technology Neutral Contract Representations


gy p

Xpath 2.0 Assertions

Federation of Two Domains

Test for Consistency of Ontologies and Compatibility of all Levels

?Relationship Ontology

Owl 2.0

SBVR Business Rules



Owl 2.0

SBVR Business Rules


?

??

SBVR Business Rules

SBVR Vocabulary• noun concepts• fact types

SBVR Rules


N3



SBVR Business Rules


SBVR Rules


N3



Domain ADomain A Domain BDomain B? Federate ?? Federate ?

If Ontologies are inconsistent at any level of the mapthen

Modify or Reject Federation Proposal/Agreementthen

If Models are compatible at all Levelsthen

C F d iCreate FederationOtherwise Modify or Reject Federation Proposal/Agreement


Composition of Two Domains

Domain ADomain A Relatio

SBVR

SBV

SBV

Technology Neut

Technology Neutra

Xpat

Inter‐Dom

a

? Compose ?? Compose ?

onship Ontology

Owl 2.0

Business Rules

VR Vocabulary•noun concepts•fact types

R Rules

tral Policy Representations

N3

al Contract Representations

h2.0 Assertions

ain Relationship M

ap

? Compose ?? Compose ?

Test for Consistencyof Ontologiesand all Levels

If Ontologies and Maps are consistentthen

??? ?

and all LevelsCreate CompositionElse

Mediate or Abandon Composition

Relationship O

n

Owl 2.0

SBVR Business

SBVR Vocabu•noun co•fact typ

SBVR Rules

Technology Neutral Policy

N3

Technology Neutral Contrac

Xpath2.0 Asse

Inter‐Dom

ain Relati

Domain BDomain B

ntology

s Rules

laryonceptspes

y Representations

ct Representations

rtions

ionship Map


Outline



Managing a Multi-Domain Environment

• Each Domain manages itself and assures that its gexposed goals, rules and policies are consistent with internal goals and policies.

l h d d d• Relationships among Domains monitored and managed via external Inter-Domain Relationship Coordinator which manages cooperation between internal domain which manages cooperation between internal domain relationship managers.

• Requires capability and tools to document ContextRequires capability and tools to document Context.• IDRC will also be responsible for monitoring and

controlling feed-back and feed-forward loops among g p gRelationship participants and constructing and maintaining Contextual Information.


Distributed Domain Relationship ManagementManagement

Domain ADomain Management System

Domain Al h

Inter-Domain Relationship Coordinator


Owl 2.0

SBVR Business R

ules

SBVR Vocabulary•noun concepts•fact types

SBVR Rules


N3


Xpath2.0 Assertions

Inter‐Dom

ain Relationship M

ap

Relationship Management Domain C

Relationship Management

Domain B R l ti hi

Domain ERelationship Management

Relationship O

ntology

Owl 2.0

SBVR Business Rules

SBVR Vocabulary•noun concepts•fact types

SBVR Rules

Technology Neutral Policy R

epresentations

N3

Technology Neutral Contract R

epresentations

Xpath2.0 Assertions

Inter‐Dom

ain Relationship Map

Domain BDomain Management System


ManagementDomain D


Relationship

Owl

SBVR Busin

SBVR Voc•nou•fact

SBVR Rules

Technology Neutral Po N

3

Technology Neutral Con

Xpath2.0 A

Inter‐Dom

ain Re p O

ntology

2.0

ness Rules

cabularyun conceptst types

s olicy Representations

3 ntract Representations

Assertions

elationship Map

Relations O

w

SBVR Bus

SBVR V •n •f

SBVR Ru

Technology Neutral

Technology Neutral Co

Xpath2.0

Inter‐Dom

ain R

?Relationship Ontology

O l 2 0



O l 2 0

Inter‐Domain Relationship Map ?Relationship Ontology

O l 2 0



O l 2 0


Domain DDomain C Domain EDomain Management System Domain Management System Domain Management System

hip Ontology

wl 2.0

siness Rules

Vocabularynoun conceptsact types

ules

Policy Representations

N3

ontract Representations

0 Assertions

Relationship Map

?

??

Owl 2.0

SBVR Business Rules


SBVR Rules


N3



Owl 2.0

SBVR Business Rules


SBVR Rules


N3



?

??

Owl 2.0

SBVR Business Rules


SBVR Rules


N3



Owl 2.0

SBVR Business Rules


SBVR Rules


N3




Traceability Maps

• Traceability Maps are a combined directed and un-y pdirected graph that document the relationships between software artifacts (processes, policies, and contracts) thru th i lif l (b i t i l t ti d their lifecycle (business, system, implementation and instance).

• Key input for Contextual information providing capability • Key input for Contextual information providing capability to perform:– Impact analysis of altering, adding or deleting a software Impact analysis of altering, adding or deleting a software

artifact,– Equivalence analysis of different combinations of software

fartifacts,– “Look-ahead” for how will system appear in future.


Multi-Domain Distributed Solution Traceability Map

• Complex distributed solutions cover many Domain p yRelationships. Traceability Maps provide a key input to the understanding of current (and potential) Context. Th R l ti hi T bilit M t b b ilt f Thus, Relationship Traceability Maps must be built for each Relationship in a Solution.

• Full Domain View Traceability Maps for each domain • Full Domain View Traceability Maps for each domain can then be constructed through the Union of the Domain Traceability Map with the Intersections of the y pDomain Traceability Map with each Relationship Traceability Map for each Federated Domain.

b ll l l b l• Combining, a Full Multi-Domain Solution Traceability Map can be constructed.

3019-Apr-10 - jjf2 ManFI - NOMS 2010

Traceability Map for Solution of Federated DomainsDomains

Composition(d2,d4)

Business Run-time/DeploymentImplementationSystem

B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1

NGOSS Container Software Artifacts(Service, Component & Application)

Map between Container DNA Fingerprint and Core NGOSS Artifacts’ DNA Fingerprints

NGOSS Use Case(s)NGOSS Use Case(s)

Business R un-time/ DeploymentI mplementationSystem

B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I 2

I 1

D4

D3

D2

D1

Policy


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I 2

I 1

D4

D3

D2

D1

Contract


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I 2

I 1

D4

D3

D2

D1

Process

reference

reference


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I 2

I 1

D4

D3

D2

D1

Policy


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I 2

I 1

D4

D3

D2

D1

Contract


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I 2

I 1

D4

D3

D2

D1

Process

reference

reference

referencereferencereference


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1





B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I 2

I 1

D4

D3

D2

D1

Policy


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I 2

I 1

D4

D3

D2

D1

Contract


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I 2

I 1

D4

D3

D2

D1

Process

reference

reference


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I 2

I 1

D4

D3

D2

D1

Policy


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I 2

I 1

D4

D3

D2

D1

Contract


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I 2

I 1

D4

D3

D2

D1

Process

reference

reference


Domain4

Domain3

p ( )Business Run- time/ DeploymentI mplementationSystem

B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

PolicyBusiness Run- time/ DeploymentI mplementationSystem

B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference

Business Run- time/ DeploymentI mplementationSystem

B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference

referencereferenceFederation Use Case

in1/out2Federation Use Case

in1/out2


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference


out1/in2

Federation Use Caseout1/in2

Federation Traceability Map

NGOSS Detailed Case(s)NGOSS Detailed Case(s) NGOSS Detailed Case(s)NGOSS Detailed Case(s) NGOSS Detailed Case(s)NGOSS Detailed Case(s)




B1 S1

I2

I1

D2

D1


B1 S1

I2

I1

D2

D1


Domain2

Composition(d1,d3) Composition(d5,d4)Business Run- time/ DeploymentI mplementationSystem

B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference



in1/out2


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference


out1/in2




B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference



in1/out2


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference


out1/in2



B2

B3

B4

B5

B6

S2

S3

SN4

SN5

I3

I4

D4

D3

D2B2

B3

B4

B5

B6

S2

S3

SN4

SN5

I3

I4

D4

D3

D2



Bu si nes s Ru n-ti me/Dep lo yme ntImpl eme nta tio nSy stem

B1

B 2B 3

B 4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I2

I1

D4

D3

D2

D1

Policy


B1

B 2B 3

B 4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I2

I1

D4

D3

D2

D1

Contract


B1

B 2B 3

B 4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I2

I1

D4

D3

D2

D1

Process

reference

reference


B1

B 2B 3

B 4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I2

I1

D4

D3

D2

D1

Policy


B1

B 2B 3

B 4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I2

I1

D4

D3

D2

D1

Contract


B1

B 2B 3

B 4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I2

I1

D4

D3

D2

D1

Process

reference

reference



2Federation(d1,d2)


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference



in1/out2


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference


out1/in2




B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1





B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I 2

I 1

D4

D3

D2

D1

Policy

Busines s R un-time/ DeploymentI mplementationSystem

B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I 2

I 1

D 4

D 3

D2

D1

Contract


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I 2

I 1

D4

D3

D2

D1

Process

reference

reference


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I 2

I 1

D4

D3

D2

D1

Policy

Busines s R un-time/ DeploymentI mplementationSystem

B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I 2

I 1

D 4

D 3

D2

D1

Contract


B1

B2B3

B4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I 2

I 1

D4

D3

D2

D1

Process

reference

reference



B1

B2

B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1


B1

B2

B3

B4

B5

B6

S1

S2

S3

SN4

SN5

I3

I4

I2

I1

D4

D3

D2

D1





B1

B 2B 3

B 4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I2

I1

D4

D3

D2

D1

Policy


B1

B 2B 3

B 4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I2

I1

D4

D3

D2

D1

Contract


B1

B 2B 3

B 4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I2

I1

D4

D3

D2

D1

Process

reference

reference


B1

B 2B 3

B 4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I2

I1

D4

D3

D2

D1

Policy


B1

B 2B 3

B 4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I2

I1

D4

D3

D2

D1

Contract


B1

B 2B 3

B 4

B5

B6

S1

S2

S3

SN4

S N5

I3

I4

I2

I1

D4

D3

D2

D1

Process

reference

reference



Domain1

Domain5Federation(d1,d5)


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference



in1/out2


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1


B1

B2B3

B4

B5

B6

S1

S2

S3

SN 4

SN 5

I 3

I4

I2

I1

D 4

D3

D 2

D 1

Contract

reference


out1/in2





Full Multi-Domain Solution Traceability Map

The Traceability Map for the full multi-domain solution can y pbe defined as:

FMDSTM = DVTMDomain1 ∪ DVTMDomain2 ∪ DVTMDomain3 ∪DVTMDomain4 ∪ DVTMDomain5

- or -

FMDSTM = (TMD1 ∪ (TMD1 ∩ TMF(D1,D2)) ∪ (TMD1 ∩TMC(D1,D3)) ∪ (TMD1 ∩ TMF(D1,D5))) ∪ (TMD2 ∪ (TMD2 ∩TM ) ∪ (TM ∩ TM )) ∪ (TM ∪ (TM ∩TMF(D1,D2)) ∪ (TMD2 ∩ TMC(D2,D4))) ∪ (TMD3 ∪ (TMD3 ∩TMC(D1,D3))) ∪ (TMD4 ∪ (TMD4 ∩ TMC(D2,D4)) ∪ (TMD4 ∩TMC(D5 D4))) ∪ (TMD5 ∪ (TMD5 ∩ TMF(D1 D5)) ∪ (TMD5 ∩


TMC(D5,D4))) ∪ (TMD5 ∪ (TMD5 ∩ TMF(D1,D5)) ∪ (TMD5 ∩TMC(D5,D4)))

Domain Relationship Management ArchitectureArchitecture

Domain Knowledge Domain Relationship MapDomain Knowledge Model

Local BusinessStrateg

Domain Relationship Map

Relationship Strategy, Goals and RulesCon

Generate

Strategy

Local BusinessGoals Technology

Neutral PolicyTechnology

Neutral Contract

strain TransformationRelationship Traceability

Map

Local BusinessRules

Neutral Policy Representations

Neutral Contract Representations

Generate Generate

Local ResourceModels

Incoming Relationship

Knowledge Model

Outgoing Relationship

Knowledge Model

Conflict Detection Knowledge

Local PoliciesGenerate

Trusted CBPMS Trusted CBPMS

DEN‐ng Knowledge Base


Trusted CBPMS Capability

Delegation Graph

Trusted CBPMS Capability Authority

Java/PHP Contract StubsAccess Control

Outline



In Summary

• New technologies (SaaS, PaaS, Cloud) require a g ( , , ) qdynamic means to build and maintain relationships between domains,

d d d d l k f• “On-demand or As-needed” linking of services/applications requires a high degree of confidence that the desired service/application will be confidence that the desired service/application will be available,

• There is a strong need to manage “the space between” There is a strong need to manage the space between domains/clouds,

• The Model must be adaptive!!p

A Model driven approach to managing inter-Domain A Model driven approach to managing inter Domain relationships provides a means to achieve all of these.


next generation management for adaptive environments manfi 2010 keynote - joel_fleck.pdf ·...

Documents