Value Delivery Modeling Language (VDML)

Transcription

OMG document number bmi/2011-05-11
Value Delivery Modeling Language
(VDML)
Revised/Initial Submission
In response to OMG Value Delivery Metamodel (VDM) RFP, Document Number bmi/09-03-09
Submission for May 23, 2011
Submitters:
Cordys
CSC
Supporters:
Aalborg University
Adaptive
Agile Enterprise Design
Enterprise Agility
SINTEF
Value Networks
XiBiX
Value Delivery Modeling Language (VDML) 1
May 23, 2011
Copyright © 2011 Aalborg University, © 2011Adaptive, © 2011 Agile Enterprise Design, ©
2011 Cordys, © 2011 CSC, © 2011 Enterprise Agility, © 2011 SINTEF, © 2011 Value
Net Works, © 2011 XiBiX
The companies listed above hereby grant a royalty-free license to the Object Management
Group, Inc. (OMG) for worldwide distribution of this document or any derivative works thereof
within OMG and to OMG members for evaluation purposes, so long as the OMG reproduces the
copyright notices and the below paragraphs on all distributed copies.
NOTICE: The information contained in this document is subject to change without notice.
The material in this document details a submission to the Object Management Group for
evaluation in accordance with the license and notices set forth on this page. This document does
not represent a commitment to implement any portion of this specification by the submitter.
WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE,
THE OBJECT MANAGEMENT GROUP AND THE COMPANIES LISTED ABOVE MAKE
NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL INCLUDING,
BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE. The Object Management Group and the
companies listed above shall not be liable for errors contained herein or for incidental or
consequential damages in connection with the furnishing, performance or use of this material.
The copyright holders listed above acknowledge that the Object Management Group (acting
itself or through its designees) is and shall at all times be the sole entity that may authorize
developers, suppliers and sellers of computer software to use certification marks, trademarks or
other special designations to indicate compliance with these materials.
The copyright owners grant member companies of the OMG permission to make a limited
number of copies of this document (up to fifty copies) for their internal use as part of the OMG
evaluation process. Use, duplication, or disclosure by government is subject to restrictions as set
forth in subdivision (c) (1) (ii) of the Right in Technical, Data and Computer Software Clause at
DFARS 252.227.7013
OMG® is a registered trademark of the Object Management Group, Inc.
May 23, 2011
Table of Contents
1
Part I Submission Information .............................................................................................. 69
1.1
1.1.1
Background ............................................................................................................. 69
1.1.2
Organization of the submission ............................................................................ 710
1.1.3
Statements of Proof of Concept ............................................................................ 811
1.2
Contributors.................................................................................................................. 811
1.2.1
Submitting organizations ...................................................................................... 811
1.2.2
Supporting organizations ...................................................................................... 811
1.3
2
Introduction .................................................................................................................... 69
Resolution of RFP Requirements ................................................................................. 912
1.3.1
Mandatory requirements ..................................................................................... 1013
1.3.2
Optional requirements ......................................................................................... 1114
1.3.3
Responses to RFP issues to be discussed............................................................ 1215
Part II VDM Specification ................................................................................................ 1417
2.1
Introduction ................................................................................................................ 1417
2.1.1
Objectives ........................................................................................................... 1417
2.1.2
Scope ................................................................................................................... 1619
2.1.3
Intended users ..................................................................................................... 1720
2.1.4
Design rationale .................................................................................................. 1821
2.1.5
Levels of compliance .......................................................................................... 2023
2.1.6
References ........................................................................................................... 2023
2.1.7
Definitions of terms ............................................................................................ 2023
2.1.8
Typographical conventions ................................................................................. 2023
2.1.9
Symbols............................................................................................................... 2023
2.2
Overview of the specification .................................................................................... 2023
2.2.1
Value Delivery .................................................................................................... 2023
2.2.2
Collaborations ..................................................................................................... 2124
2.2.3
Activities, flows and deliverables ....................................................................... 2326
2.2.4
Value Chain ........................................................................................................ 2326
2.2.5
Capabilities ......................................................................................................... 2427
May 23, 2011
2.2.6
Risk Analysis ...................................................................................................... 2427
2.2.7
Value network ..................................................................................................... 2528
2.2.8
Business Models ................................................................................................. 2528
2.2.9
REA (Resource-Event-Agent) ............................................................................ 2629
2.2.10
Metrics ................................................................................................................ 2629
2.2.11
Extensibility ........................................................................................................ 2629
2.3
Model elements .......................................................................................................... 2730
2.3.1
Summary of Packages ......................................................................................... 2730
2.3.2
Collaborations Package ....................................................................................... 2932
2.3.3
Values Package ................................................................................................... 4245
2.3.4
Org Units Package .............................................................................................. 4548
2.3.5
Capabilities Package ........................................................................................... 4750
2.3.6
Processes Package ............................................................................................... 5356
2.3.7
Cases Package ..................................................................................................... 5457
2.3.8
Applications Package .......................................................................................... 5558
2.3.9
Value Chains Package......................................................................................... 5558
2.3.10
Business Relationships Package ......................................................................... 5861
2.3.11
Communities Package ......................................................................................... 5962
2.3.12
Metrics ................................................................................................................ 6265
2.3.13
Business Models Package ................................................................................... 6467
2.3.14
Libraries Package ................................................................................................ 6669
2.3.15
Risk Factors Package .......................................................................................... 7679
2.4
Extension Definitions ................................................................................................. 7881
2.4.2
Collaboration Extensions .................................................................................... 8184
2.4.3
Value Proposition Extensions ............................................................................. 8285
2.4.4
Org Unit Extensions ............................................................................................ 8386
2.4.5
Capability Extensions ......................................................................................... 8386
2.4.6
Machine Extensions ............................................................................................ 8487
2.4.7
Process Extensions .............................................................................................. 8588
2.4.8
Case Extensions .................................................................................................. 8588
May 23, 2011
3
2.4.9
Application Extensions ....................................................................................... 8689
2.4.10
Value Chain Extensions ...................................................................................... 8689
2.4.11
Business Relationship Extensions....................................................................... 8790
2.4.12
Community Extensions ....................................................................................... 8790
2.4.13
Metric Extensions ............................................................................................... 8891
2.4.14
Business Model Extensions ................................................................................ 8891
2.4.15
Library Extensions .............................................................................................. 8891
2.4.16
Risk Factor Extensions ....................................................................................... 8992
Appendices........................................................................................................................ 9093
3.1
References (non-normative) ....................................................................................... 9093
3.2
Glossary (non-normative) .......................................................................................... 9194
3.3
Library (normative) .................................................................................................... 9295
3.4
Related OMG specifications (normative) .................................................................. 9295
3.5
Notation Examples (non-normative) .......................................................................... 9396
3.6
Supporting Examples (non-normative) .................................................................... 97100
May 23, 2011
1 Part I Submission Information
This part of the submission pertains to the submission process and is not part of the submitted
specification, per se. As such, the content of this part will not appear in a final adopted
specification.
1.1 Introduction
This section provides a context for the submission.
1.1.1 Background
This submission proposes a metamodel, i.e., a modeling language for modeling the development,
management and exchange of value both within a business and with business partners and
customers.
Two important trends have emerged in conversations about value creation in business. The first
trend is toward considering both financial and non-financial forms of value. Drivers for this are a
growing focus since the mid-1990s on intangible assets, Enhanced Business Reporting Language
such as XBRL, and increasing concern with sustainability and the positive or negative value
impact of business activities on society, industries and the environment.
The second trend is the increasing importance of business networks and collaborations across
enterprise boundaries and a desire to show the value creation dynamics of such collaborations.
Taken together these two trends must be considered in any effort to model value delivery within
and between enterprises.
Historically, value chain modeling was introduced by Michael Porter in his 1985 book. It has
been used in strategic planning at an executive level for many years. It brings a focus on
delivery of value to customers and the capabilities that produce that value.
The value chain is a well-established framework for analysis of customer value. The values of a
value proposition seen by the customer are traceable back through the value chain to the
activities that contribute those values so that they can be maintained or enhanced. The value
chain can extend beyond the specific enterprise to encompass exchanges with customers and
suppliers in the broader enterprise. Each participant in an exchange provides and receives values
from other participants. Each must realize a net gain to be a viable participant.
A related framework is that of capabilities. The identification of capabilities provides an abstract
structure for the enterprise and for identification of particular segments of the business operation
where performance could be improved or competitive advantage could be enhanced. Capability
analysis is a common practice where capabilities for value creation are defined, typically in a
hierarchy but without always being linked to customer value as provided by Porter’s value chain.
May 23, 2011
The identification of capabilities includes consideration of the sharing of capabilities such as for
economies of scale or improved control in multiple lines of business. This sharing of capabilities
aligns with the concept of a service-oriented architecture (SOA) where capabilities are exposed
as services to be applied in multiple business contexts.
Clearly, the use of a value chain model to define the uses of capabilities and/or services provides
a cross-enterprise perspective on the contributions of value and capability requirements for
business improvement and transformation, which includes discovery of processes or process
improvements However, there are a number of different approaches and applications of value
chain modeling and other value delivery models such as value streams, activity networks and
value networks.
It is believed that a more robust, computer-based modeling capability could support the needs
represented by these variants with an integrated Value Delivery Modeling Language (VDML) In
particular, the Value Delivery Metamodel has been refined to support Value Network analysis,
e3-value modeling, and a business model viewpoint (a stakeholder perspective). Additional
work is required to address REA (Resource Event Agent) viewpoint.
After development of an initial submission for the Value Delivery Metamodel RFP, the
NEFFICS (Networked Enterprise transFormation and resource management in Future internet
enabled Innovation CloudS) project was initiated by the European Union. This project is
intended to leverage work on the Value Delivery Metamodel RFP submission, and has engaged a
number of industry experts to contribute to the project. This provided additional perspective and
expertise for the submission.
In the following sub-sections, we will discuss the intended users of this specification, the
organization of the submission, the design rationale of the specification and statements of proof
of concepts.
1.1.2 Organization of the submission
This submission is structured in two primary parts: the Submission Information (Part I) and the
VDML Specification (Part II), along with an Appendix.
Part I is non-normative and is not intended to be part of a final specification. It provides a
context for consideration of the submission.
Part II is the proposed specification that is normative and defines the structure of a compliant
metamodel.
The Appendix provides references, a Glossary, a library of normative extensions to the
extensible elements, references to related specifications, and supporting examples.
May 23, 2011
1.1.3 Statements of Proof of Concept
Many concepts and relationships represented in this metamodel are derived from existing
business modeling techniques. These techniques have been supported by participants in the
submission development who have extensive experience in the design and transformation of
businesses.
This metamodel leverages these insights and extends them to provide a more comprehensive,
integrated representation of the management, development and exchange of values. As this
specification is being developedit is being implemented. Such implementations will further
validate and demonstrate the application of the metamodel.
In addition, Value Network Analysis (VNA), e3Value and REA are current business analysis
practices that can be supported by the VDML metamodel. Support for theise practices is being
incorporated into VDML
1.2 Contributors
This sub-section identifies the organizations and representatives that are formal submitters of this
specification as well as those that supported the effort on a less formal basis.
1.2.1 Submitting organizations
Cordys
Henk de Man, [email protected]
Field Code Changed
Mudigonda Rajender, [email protected]
Formatted: Spanish (Spain-Traditional Sort)
CSC
Pavel Hruby [email protected]
Klaus Loehnert [email protected]
1.2.2 Supporting organizations
Aalborg University
Peter Lindgren [email protected]
Adaptive
Pete Rivett [email protected]
Agile Enterprise Design
Fred Cummins [email protected]
Enterprise Agility
Neal McWhorter, [email protected]
May 23, 2011
SINTEF
Arne Berre, [email protected]
Value Networks
Verna Allee [email protected]
Field Code Changed
XiBiX
Ton Soetekouw,[email protected]
1.3 Resolution of RFP Requirements
This section responds to the specific requirements stated in the RFP.
May 23, 2011
1.3.1 Mandatory requirements
1.3.1.1 Requirement
MOF metamodel
Specification
The metamodel is a MOF metamodel
Submissions shall represent the value delivery
metamodel as a MOF metamodel.
Robust representation
A value delivery model shall provide sufficient
detail to represent the participation of operational
business capabilities in value delivery including
measures for concrete activities and for
aggregation into higher level abstractions.
Support abstractions for different concerns
A value delivery model shall provide abstractions
for different areas of concern including an
enterprise executive view, operational views, and
the ability to expand high-level abstractions to
supporting operational detail.
Representation of customer value
differentiators and associated activities
A value delivery model shall provide
representation of customer value to identify
differentiators and the associated activities and
capabilities that produce the associated value add.
Relationship to organization models
Appropriate value delivery model abstractions
shall provide for linkage to associated business
organizations responsible for the activities or
groups of activities so that appropriate
organizational responsibilities are represented in
value delivery models at different levels of detail.
Events and constraints
The metamodel supports representation of
operational level activities and aggregation to
higher-level abstractions including the interactions
of a network of enterprises, agencies, communities
or organizations.
The model supports abstractions of activities, a
hierarchy of business capabilities, collaborations
androles relationships that develop or exchange
value, enterprise-level exchanges of value
including outsourcing, and a business model
(stakeholder view of the business operation). An
REA viewpoint is planned for a subsequent version
of this submission.
Value propositions identify the values that are
important to recipients of value including those in
the role of customers. Sources of value can be
linked back to activities that contribute value and
capabilities that perform those activities.
Analysis of value development and exchange
involves the participation and relationships of
people and organizations. These relationships go
well beyond the traditional organization hierarchy.
Consequently, VDML includes an organization
modeling capability where these relationships are
represented by collaborations and roles in those
collaborations. This provides a consistent structure
to address not only the traditional management
hierarchy, but relationships defined by
participation in a process, transactions between
enterprises, participation in the delivery of value,
participation in more loosely structured
communities, and so on.
Dependencies represent events and constraints in
terms of output of activities (events) and the
May 23, 2011
1.3.1.1 Requirement
The metamodel shall provide for the representation
of events that affect value chain timing and
throughput and constraints that link the events to
dependent activities.
Capability characteristics
The metamodel shall provide for the capture of
capability characteristics such as types of
resources, facilities, methods and technology to
support the identification of similar capabilities
that might be consolidated or used interchangeably
Cost and performance variables
The metamodel shall provide for the capture of
cost and duration variables and support for the
computation of estimated value chain costs and
timeliness of delivery. Representation of the
details of cost and time computations are outside
the scope of this specification.
Extensibility
The metamodel shall utilize MOF extensibility
features to enable users to add specifications of
additional capability and dependency
characteristics.
Specification
associated input dependencies (constraints) of other
activities.
A capability definition/type element captures the
characteristics of capabilities. User-defined
properties can further characterize capabilities, as
well as their contributions to value chains.
Contributions of activities to cost and duration, as
well as quality-related metrics, are associated with
the deliverables produced by activities including
activities that define a value chain. These elements
support the computation of value for value
propositions as well as for performance reporting
VDML includes an extension mechanism that
allows users to define specialized element types
and add properties, including metrics. This
extensibility feature is based on the extensibility
feature of BPMN.
1.3.2 Optional requirements
Normative views and notations
Submissions may include normative views and
notations for expressing value delivery models
Relationship to business process models
At an operational level, a value delivery model may
define the relationship of value delivery activities
to the business processes that perform the value
delivery activities through references to points in
business processes where a work product is
Notation for primary views is included. (under
development). It is expected that additional views
and notations will be developed by implementers.
Capabilities that support value chain activities
provide for identification of supporting business
processes and applications.
May 23, 2011
transferred from one capability to another.
Organization hierarchy
Submissions may provide for specification of an
organization hierarchy for analysis of the
aggregation of capabilities for cross-capability
optimization (such as production scheduling
through multiple phases of manufacturing).
Integration of support services
Submissions may include the linkage of support
services value delivery models to primary value
delivery models.
Specification of activities
The model includes representation of business roles
and relationships as collaborations that are
specialized for particular types of activities such as
the reporting structure of a management hierarchy.
The model includes the ability to define linkages to
support services and will also support modeling of
the value delivery models for support services
serving internal customers.
The model supports consideration of different time,
cost and quality metrics for key value deliverables.
Submissions may provide for specification of the
different activities performed by a capability for
different products or lines of business as a basis for
definition of associated costs and durations.
Alignment with BMM
A submission shall define the alignment of the
value delivery model with the Business Motivation
Model in support of strategic planning.
There is no direct connection with the BMM
metamodel nor overlap of concepts at this time. A
value delivery model will support evaluation of the
impact of influencers, relationships with business
partners, analysis of competitive position through
consideration of value propositions and the
definition of initiatives, but these links are
determined by management planning and decisionmaking.
1.3.3 Responses to RFP issues to be discussed
Views supported
TBD
Submitters shall discuss the users and content
characteristics of views that are supported by value
delivery models.
Support for value delivery model development
See examples in Appendix (under development)
Submitters shall discuss how a value delivery
model can be developed as for planning a new
product from concept through customer delivery.
Relationship to strategic planning models
A VDML model supports analysis of the
development and exchange of values internally and
May 23, 2011
Submitters shall discuss how value delivery models
will support strategic planning, specifically as
related to BMM.
Relationship to SOA
Submitters shall discuss how value delivery models
are related to a Service Oriented Architecture
(SOA) and SoaML.
Relationship to BPMN
Submissions shall discuss the relationships of the
metamodel to BPMN and how BPMN and value
chain models might be aligned.
with customers and business partners. Users may
modify a model to consider the impact on value
delivery and performance metrics, and users may
create to-be models to define phases of business
transformation to a future state.
Capabilities can be configured as sharable services
with defined interfaces. Such capabilities will be
required where the same capability supports
multiple lines of business, i.e., multiple value
chains.
VDML provides a business operation abstraction
focused on the creation and exchange of value
associated with deliverables. BPMN focuses on
coordination and control of the operation of the
business. Effectively, VDML describes WHAT the
business does or must do to create and exchange
value while BPDM defines HOW the business
operates at a more detailed level.
A sequence of VDML activities may be the basis
for creation of corresponding activities in a BPDM
process, but such a process will not include aspects
of coordination and control that achieve operational
efficiency, policy compliance and quality of
operations.
Relationship to Chain, Shop and Network
Enterprises
Value chain, shop and network models described
by Stabell and Fjeldstad can all be modeled with
VDML.
Submissions shall discuss how the metamodel
applies to chain, shop and network enterprise
models as described by Stabell and Fjeldstad.
May 23, 2011
2 Part II VDM Specification
This section defines the VDML specification. It starts with general information about the
specification, provides an overview of the metamodel, defines the model elements, and defines
the elements that provide for user extensions.
2.1 Introduction
This section defines general information regarding the VDML metamodel specification:
objectives, scope, levels of compliance, references, definitions of terms, typographical
conventions and symbols.
2.1.1 Objectives
The VDML metamodel addresses the following modeling objectives:
2.1.1.1 Link value delivery to activities
The model should identify values of interest to customers and other stakeholders, both those that
are met and those that are of concern. A VDML model should enable the business analyst to
identify the activities that are sources or potential sources of these values. Values may depend on
specific activities, a combination of activities or the flow of deliverables between activities.
2.1.1.2 Identify the characteristics of capabilities
Capabilities determine the ability of the enterprise to perform required activities. The values
associated with the deliverables of an activity depend on a capability to perform that activity. A
capability model element identifies the facilities, resources, assets, process(es), intellectual
capital, etc., that are managed to perform an activity. Identification of these characteristics
enables consideration of the adequacy of existing capabilities, and it supports consideration of
similarities of capabilities that may be aggregated and shared to achieve economies of scale.
2.1.1.3 Provide levels of abstraction
A complete VDML model may involve many organizational relationships, capabilities and
dependencies and networks of value development and exchange. An implementation should be
able to provide relatively high level abstractions with the ability to selectively expand the detail
to understand specific contributions and dependencies.
2.1.1.4 Map capabilities to responsible organizations
A capability may be provided by an organization that also provides similar capabilities in support
of other activities. Each capability may not be clearly distinguishable in the work done by the
organization since they may share resources. The VDML user must be able to identify required
capabilities independent of the currently responsible organizations, and then be able to explore
May 23, 2011
the re-alignment of capabilities to organizations for potential synergy, economy of scale and
consistency of operations as well as possible out-sourcing.
2.1.1.5 Support analysis of value requirements and sources of value from activities in
a value chain
Value chain analysis may be applied to any production of a product or service including products
and services performed for internal customers. The values required by the recipient of a product
or service must be evaluated against the values currently or potentially produced by a value chain
along with information on the activities and associated capabilities that contribute to those
values.
2.1.1.6 Support capability consolidation
At a detailed level, an enterprise will have different value chains for different products or lines of
business. Some of the capabilities will be required in multiple value chains. The model must
support identification of similar capabilities and consideration of consolidation.
2.1.1.7 Identify opportunities for process improvement
Business processes determine when capabilities are engaged and how they are performed. The
model should support identification of opportunities to improve customer value by focusing on
critical capabilities and understanding their dependencies on inputs from other capabilities.
2.1.1.8 Optimize across multiple lines of business
The Value Delivery Model will provide the context for considering the implications of multiple
lines of business to the implementation and integration of capabilities. This provides an
opportunity for understanding the enterprise consequences of changes and trade-offs between
multiple lines of business as well as priorities for investments.
2.1.1.9 Relationships with customers and business partners
The model must link the development and exchange of values within the business to the
exchanges of deliverables and associated values with customers and business partners including
participation in an extended enterprise.
2.1.1.10 Support analysis of value exchanges in an enterprise ecosystem
An enterprise exists in an ecosystem of relationships with other enterprises. VDML should
support analysis of an extended value exchange network to identify relationships with key
business partners and customers.
May 23, 2011
2.1.1.11 Support for related analysis techniques
The VDML metamodel should support related analysis techniques such as Value Networks,
e3Value and REA and where possible provide a clear pathway for integration with Lean, Six
Sigma, BPM, value stream analysis and business modeling approaches.
2.1.2 Scope
This section outlines the scope of concepts included in the value delivery metamodel.
2.1.2.1 Value
Value is considered broadly in the VDML and is user defined. Value can be financial or nonfinancial value, tangible or intangible.
Examples of tangible value include contracts and invoices, return receipt of orders, request for
proposals, confirmations, and payment, products and services that generate revenue.
Intangible value typical takes the form of informal, non-contractual activities, deliverables or
benefits that help build business relationships and contribute to operational effectiveness.
Examples might be strategic information, planning knowledge, process knowledge, technical
know-how, design ideas, or advantages.
2.1.2.2 Activity networks
Central to a value delivery model is the activity network. Activities, which can include value
chain activities, represent contributions of work that generate deliverables (contributions) to
customer value. High level activities can be expanded to expose more detailed activities.
2.1.2.3 Capabilities and services
A capability represents the ability to perform a type of work that can contribute value for
stakeholders. It includes facilities, personnel with particular skills, technical disciplines,
information and process technology, etc. that are needed to perform associated activities. Some
capabilities will qualify as service units that have well-defined interfaces (services) so that they
can be engaged in multiple contexts.
2.1.2.4 Value contributions and value proposition
The model will represent support for the identification of values desired by a stakeholder,
represented by a value proposition, and the ability to trace the sources of these values back to
contributing activities.
2.1.2.5 Value networks
A value network represents exchanges of value between roles or collaborations. A value
network can focus on the exchanges of value for a particular line of business or extended
enterprise where participants exchange value for their mutual benefit. An exchange involves two
or more roles. The typical exchange might be between a provider of a product or service and a
May 23, 2011
customer. However, exchanges occur in other contexts as well, and may occur between roles or
collaborations within a company. This provides the basis for consideration of a broader,
business ecosystem involving multiple business entities such as the relationships between an
internet news provider, news reporters, advertisers and readers. The value network model scales
from small work groups, to innovation networks, business ecosystems, industries and even
global action networks.
2.1.2.6 Organizations
Value are developed, managed and exchanged by people and organizations. Analysis of value
requires consideration of the people and organizations involved and their relationships. VDML
models these relationships as collaborations and roles within collaborations. The scope of
collaborations modeled will be up the discretion of the user but will necessarily include
collaborations that involve the development, management and exchange of value in the domain
of interest.
The collaboration concept extends to members of communities, professional organizations,
market segments and other associations of people and/or organizations. An individual
participant (such as an individual person or business entity) may be engaged in multiple roles in
different collaborations.
2.1.2.7 Business processes and applications
The model does not include specification of the design of business processes and computer
applications, but provides for identification of processes and applications associated with value
creation activities, value flows and value exchanges. Since processes and applications can
engage people and organizations in participating roles, the processes and applications are viewed
as collaborations so these interactions can be included in a VDML model.
2.1.2.8 Performance metrics
The model provides for the capture of value contributions and performance metrics such as cost,
duration and defects, the specification of targets and computation of cumulative effects. Metrics
can include measures of variance that may support risk assessment. Metrics also support
measurement of aspects of stakeholder value, as well as computational relationships between
performance and value properties as well as recipient levels of value satisfaction. Metrics also
can include specification of variance for risk analysis.
2.1.3 Intended users
This document is intended for vendors that intend to implement value delivery modeling
products, and for those interested OMG members who will learn from, leverage, and vote on this
specification.
May 23, 2011
Value delivery modeling that will result from implementation of this specification is intended for
business executives, business managers, business analysts and information technology leaders
who are responsible for the governance, design, management, transformation, and automation of
the enterprise.
2.1.4 Design rationale
This submission reflects a number of assumptions of the submitters. These assumptions have
guided the development of the specification.
2.1.4.1 Business perspective
VDML models are expected to be used primarily by business people. Consequently, the
visualizations and terminology should be appropriate for business people and, if possible,
familiar.
2.1.4.2 As-is and to-be models
Modelers should be able to capture appropriate elements of the business as it exists or as it
should exist in the future. Users of VDML models should be able to (1) capture the implicit
value chains, value activities, and value exchanges that exist in the enterprise and with related
enterprises, (2) develop a strategic value delivery and exchange structure, and (3) represent
intermediate models of the enterprise and key collaborations within and between enterprises in
transition from as-is to to-be.
2.1.4.3 Viewpoints
VDML models will be used by a number of different communities of interest, and the modeling
tools should provide appropriate viewpoints for these different communities. For example,
executives will want high-level abstractions with the ability to drill down to focus on specific
areas of concern as well as responsible people and organizations; business analysts will want to
focus on the relationship to business processes and services as well as definition and organization
of capabilities; IT leaders will want to understand the opportunities and priorities for application
of technology (in particular process automation technology); capability managers will want to
understand their impact on customer value and the lines of business they support, and so on.
2.1.4.4 Abstractions
A comprehensive VDML model may be very complex. Developers and users of the model will
need to be able to view and work with the model using meaningful abstractions so they need not
comprehend all of the complexity at once.
2.1.4.5 Creation and exchange of value
The creation and exchange of value is a core theme of VDML. Value propositions define the
relationship between values created and values desired by customers and stakeholders. Value is
May 23, 2011
created by activities. Such activities generate deliverables that convey value through flows or
exchanges between activities of roles within an enterprise or with business partners and
customers. The patterns of such value flows and exchanges define relationships between
businesses business and are the basis for assessing the viability of those relationships.
2.1.4.6 Capabilities and services
Any enterprise has capabilities that contribute to the delivery of customer value. These
capabilities may not be explicit in the processes and organization structure, but can be identified
for purposes of understanding how value is created and delivered. The same capabilities may be
exposed as services for sharing, and may be explicitly identified with responsible organizations
to achieve the agility and economies of scale of a service oriented architecture.
2.1.4.7 Organizations
Organizational structure typically is defined by the relationships between people for various
purposes. However, the traditional management hierarchy does not address many important roles
and relationships, Cross boundary collaborations, informal roles and fluid relationships are
important for defining responsibilities in the creation and exchange of value. VDML provides a
core concept of a collaboration involving participants in defined roles, of which that traditional
management hierarchy may be just one of many collaborations that can be represented.
2.1.4.8 Alignment to processes and applications
The VDML model provides an abstraction on business operations that focuses on the activities
performed (by application of capabilities) and the inputs and outputs of those activities that result
in business value. The VDML model does not expose the finely detailed business processes and
computer applications by which activities are orchestrated and implemented. However, the
model should provide appropriate linkage to the processes and applications so that the
involvement of people and organizations can be identified, and their impact on customer value
and needs for improvement can be considered.
2.1.4.9 Model exchange
As with all OMG specifications, the goal of this specification is to support the exchange of
models between VDML modeling tools. In addition, the concepts and visualizations should
support the ability of users and developers of the models to understand and discuss models in
different modeling tools.
2.1.4.10 Compatibility with other specifications
Concepts in VDML models are related to concepts in other OMG business modeling languages.
VDML activities are associated with business processes, organizations and applications. VDML
capabilities will be exposed as services in a SOA. VDML collaborations comprehend
relationships between people and organizations that may take different forms in other
May 23, 2011
specifications such as the participants in process roles, and the roles in the interactions between
enterprises. Representation of these concepts should be compatible with their representation in
these other models, but it must be understood that VDML provides a different viewpoint on these
elements.
2.1.5 Levels of compliance
TBD
2.1.6 References
A list of references is included in the Appendix.
2.1.7 Definitions of terms
The following overview section provides definitions of some key terms and concepts used in the
metamodel. These and additional definitions of terms are provided in the Glossary of the
Appendix.
2.1.8 Typographical conventions
[e.g., use of bold, italic or special fonts in the expression of the metamodel specification—TBD]
2.1.9 Symbols
Symbols used in the representation of the metamodel are consistent with standard UML.
Symbols used for VDML notation are defined with each associated view specification (TBD).
2.2 Overview of the specification
This section provides an overview of the VDML modeling capabilities.
2.2.1 Value Delivery
Delivery of value is a central theme of VDML. Value is a characteristic of something provided
that affects its appeal to a recipient. The value of a deliverable (e.g., product) includes its fitness
for purpose for the deliverable recipient (e.g., customer) but also may include such factors as its
reliability, the availability of supporting services, the reputation of the value provider (e.g.,
supplier), and prestige enjoyed by the customer. It is the creation and exchange of value that
drives business activity.
Businesses provide value to stakeholders to realize profit or some other kind of gain. In the case
of sales to a customer, they provide value in order to gain a financial return so that they can
realize a profit. In other cases, gain is achieved through exchanges of other types of value such
as participation in an industry standards organization in order to gain early insight into market
trends and visibility for their brand. Government and academic institutions must realize nonfinancial values as measures of their success. The creation of value is often supported by
May 23, 2011
suppliers that provide value in their products and services. Within a business, value is generated
through activities that collectively deliver the end product or service or provide supporting
activities that generate other kinds of gains for the enterprise.
The package of values offered to a recipient can be described as a value proposition. The value
proposition reflects the interests of a particular stakeholder or recipient community (e.g., a
market segment), at least as the provider perceives the interests. Critical measures of value
include measures of stakeholder satisfaction as well as the price they are willing to pay if it is an
offering designed to generate direct revenue.
In general, the end product or service has some intrinsic value that reflects the primary need of
the purchaser. However, there are generally other values that affect the transaction. The value
propositions associated with products will likely go beyond the exchange of parts for money, but
will include quality, timeliness of delivery, quality of specifications, and stability of schedules
from a manufacturer. Exchange of values generally also goes beyond product exchanged for
payment. This includes more intangible values such as sharing knowledge, opportunities for codevelopment or co-production, the use of lower priced materials, or the opportunities to enter
new markets or regions.
The value proposition also provides for a weighted average of these satisfaction measures to
suggest an overall stakeholder satisfaction. From the purchaser’s point of view, the net value of
the value proposition must exceed the net cost of the value provided by the purchaser or recipient
to accept the value proposition. The costs of obtaining value are typically payment, but can be
other values such as reference-ability or guarantees of future purchases.
There is more to the operation of a business than just the mainstream value creating operations.
The work of the business is defined by activities. There are activities to: develop products and
services; develop and maintain the capabilities needed to perform the mainstream activities;
manage financial transactions; manage people; manage information; develop and assess markets;
develop best practices; and manage planning and decision-making. All these activities deliver
internal value or achieve business gains that are necessary to the success of the business - and all
of these activities are linked together. These links extend beyond enterprise boundaries to
business partners and various business relationships, including professional communities, where
participants exchange value for their mutual benefit. Links define the delivery of value as flows
and exchanges between the activities of people and organizations. Note that in some
visualizations, the activities will be elided so that flows appear between participants or their
roles.
2.2.2 Collaborations
In business the creation and exchanges of value take various forms where people and
organizations work together to achieve some mutual benefit or to jointly achieve desired
value(s). In VDML, these mutually beneficial relationships are described as collaborations. Two
or more companies collaborate for profit, where an internet publisher, advertisers, content
May 23, 2011
providers and consumers interact with each other in a marketplace. The participants in this
commercial collaboration each have roles, described as publisher, content provider, advertiser
and consumer. The roles describe how each is viewed by the others in the collaboration, and
they define the responsibilities of each participant in the collaboration.
Each of the participants performs activities to engage in the collaboration, and each may have a
supporting network of activities that consume and produce the values received and provided in
the commercial collaboration. Any given participant, such as an individual or a business entity
can play one or several roles in a collaboration.
The concept of collaboration applies, not only to interactions between companies, but to all
organized behavior. A department or group involves a collaboration among its members to
fulfill the purpose or generate the value contribution of the department or group. The traditional
management hierarchy is a hierarchy of collaborations described in VDML as organization units
(OU). However, there are many other collaborations that are not described in the traditional
management hierarchy. For example, a project is a collaboration among team members to
achieve the purpose of the project. Executing a buslness process requires a collaboration among
participants, and, indeed, “role” is a basic concept in process management. A committee or task
force also is a collaboration between roles. A professional society or standards organization is a
community collaboration that can also be described as a set of roles and value interactions.
In each of these forms of collaboration, there are participants in roles with a shared purpose
working for their mutual benefit to achieve a purpose that is enhanced by synergy among the
members. The participants may be actors (people or automated agents), or other collaborations.
In addition, a participant in a role may be qualified because it participates in a role in another
collaboration. For example, a manager of a department may be required to be an employee (a
role in the company), or a member of a specification review committee may be required to be a
representative of a particular stakeholder. In VDML this is modeled as a role filled by a role so
that the actual participant(s) can be identified as well as the basis for their participation.
Participation in a collaboration is motivated by the mutual benefits received by the participants
or a mutual objective. In most cases, the collaboration as a unit provides value through
participation in other collaborations. Such a value contribution typically is provided in exchange
for compensating value received for the benefit of the members. An example would be a project
team delivering a solution that is paid for by a client through a larger engagement. The project
team is itself a participant in a larger, internal organization unit (collaboration), such as Service
Delivery, that receives a share of profit and pays the project team members for their efforts.
VDML defines a number of specializations of the concept of collaboration that represent
commonly occurring types of collaboration. These types provide a foundation for analysis of
interactions in the creation and exchange of value in an enterprise, including an extended
enterprise. VDML also defines a number of types of roles associated with the defined types of
collaboration. These fundamental types enable specialized logic in supporting tools for editing
May 23, 2011
and analysis of VDML models, and they provide consistency of terminology and semantics for
sharing and exchange of models.
2.2.3 Activities, flows and deliverables
Participants in collaborations perform activities through performing their roles. An activity
describes work that is required from the role. Each activity has inputs and outputs, described as
deliverables. Inputs to an activity are generally deliverables from other activities (although input
deliverables may not always be represented, explicitly). The transfer of a deliverable from one
activity to another is described as a flow or dependency. Deliverables may be products or other
forms that convey value, including messages that convey ownership, commitment, and other
kinds of intangible value from one participant to another.
In describing a business relationship between companies, the focus may be on high-level
abstractions of the activities that each contributes to the collaboration. The abstract view may
simply depict the flow of deliverables and associated values between participants. However,
with VDML a collaboration may be examined more closely to view the network of activities and
roles that make up the collaboration, possibly including roles of collaborations that provide
shared services.
Activities connected by deliverable flows can have a form similar to a PERT (Program
Evaluation and Review Technique) network of activities and their dependencies. The activities
and flows can model value added (or degraded) and their associated performance metrics.
Each of the contributions to values and performance metrics can be captured in a list that allows
(1) aggregation of the contributions of multiple activities and flows to the same value or
performance metric, and (2) traceability from the end product or service back to the activities and
capabilities responsible for each value or performance metric.
2.2.4 Value Chain
An activity network involved in the delivery of a product or services may be represented as a
value chain. A value chain is modeled as a collaboration where capabilities are engaged to
perform activities. A value chain links the capabilities that do the work to the values of interest to
a customer or other stakeholder so recipient value drives improvements. A value chain typically
models the operation of a product line or line of business, but it may also model internal
operations, such as financial services or purchasing services, that serve internal customers. A
value chain collaboration participates in a responsibility role in an organization unit that is
responsible for management of the value chain.
Each role in a value chain must be filled by a capability (as a collaboration) that performs the
activity. In addition, for a value chain, flows may reference inventories. An inventory represents
a store of deliverables, typically a result of batch processing, produced in anticipation of need.
Inventories can reduce time to delivery to a customer but may also introduce additional costs.
May 23, 2011
VDML supports analysis of the business impact of changes in the activity network and the
supporting capabilities on the value proposition. Where the value delivery falls short, the
activities that impact that value delivery can be identified and improvement considered.
Value chain analysis also supports consideration of consolidation for economies of scale of
capabilities that occur in multiple value chains.
2.2.5 Capabilities
A capability is a bundle of facilities, resources, assets, process(es), intellectual capital, and so on
that are managed together to perform a type of work. VDML provides for specification of a
capability definition that defines the requirements of a capability, and a capability (instance) that
defines the specific realization of a capability definition within a business organization. A
capability (instance) may be viewed as a type of collaboration because it involves the
participation of actors (e.g., people) and possibly other organizations to perform the particular
work.
In an activity network, an activity defines work to be done, and identifies a capability definition
that describes what is required to do the work. A value chain activity identifies a role that must
be filled by a capability (instance). The assignment of a capability to an activity role binds the
activity to a particular part of the business organization that is expected to provide the capability
(i.e., meet the requirements of a capability definition) and perform the activity.
In a business that is organized around lines of business, each line of business may be relatively
independent and include the necessary capabilities to deliver its product or service. In a more
integrated business, capabilities may be shared across lines of business. Then a capability may
be viewed as a shared service with a defined interface through which the service is accessed.
Generally, like a project team, a capability as a collaboration is not the same as an organization
unit in the management hierarchy, but it may engage the resources of an organization unit. A
capability is identified as filling a responsibility role in the organization unit that manages it.
Furthermore, a capability may be one of a bundle of capabilities managed by an organization unit
to share resources, practices and intellectual capital for economies of scale. So when an activity
engages a capability, the responsible organization unit determines how the necessary elements
are brought together to satisfy the capability requirements of that activity (e.g., how to perform
the service). This linkage to an organization unit provides accountability of the organization unit
for the impact of its capability management on the values delivered by the lines of business it
supports.
2.2.6 Risk Analysis
Business risk is associated with the potential failure to deliver appropriate value. VDML models
how the business creates and delivers value, and can support impact analysis of potential risk
scenarios.
May 23, 2011
Variance in value contributions and performance variables can be traced to the impact on value
propositions. The impact of failure of an activity or a flow can be assessed based on
dependencies and propagation of effect considering deliverable transport times and inventories.
The impact of a capability failure can be assessed in terms of its impact on multiple lines of
business and consideration of potential alternative sources of the required services.
Risk scenarios can be considered where multiple capabilities may be affected by a single event
such as a natural disaster.
2.2.7 Value network
There is an increasing desire to model the value creation dynamics of business networks and
collaborations that cross enterprise boundaries. In some cases Value Chain Models are being
integrated with Value Network Models such as Value Network Analysis (VNA).
VDML supports analysis of the creation and consumption of values by enterprises and
organizations at all levels and provides for smooth transitions between value chain views of
value delivery and value network views. VDML not only provides the ability to consider the
impact of values that are not directly associated with delivery of a product or service to a
customer, but with its emphasis on roles and collaborations provides a way to model value
delivery with the perspective of a collaborative network. Therefore it is useful for showing the
mechanics of value delivery within the enterprise and the dynamics of value delivery across
enterprises, industries and even global networks.
For example, value is exchanged by participants in an industry standards organization. What is
the business value and how does it impact the business? VDML provides an environment in
which these values can be identified and traced both for internal impact, and for the impact on
relationships with customers, business partners and other stakeholders.
The analysis of value can also be extended to internal support services and collaborations such as
finance, purchasing, human resources, facilities maintenance and information services. These
provide value to internal customers that, in turn, impact the capabilities and efficiencies of
mainstream operations.
This analysis helps establish the importance of activities and collaborations that do not have a
simple product cost or profit impact, but can have significant impact on the success of the
enterprise. This additional modeling capability makes VDML an appropriate modeling approach
not only for enterprise, but also for non-profits or NGOs, government agencies and community
efforts.
2.2.8 Business Models
The term business model is commonly used to describe a high-level abstraction of the key
building blocks of a business. Different practitioners may focus on somewhat different building
May 23, 2011
blocks. These components can be mapped to a VDML model to provide more detailed support
for the abstractions, their relationships and their viability.
Osterwalder defines 9 building blocks
1. Customer segment
2. Value proposition
3. Channels
4. Customer relationship
5. Revenue streams
6. Key resources
7. Key activities
8. Key partnerships
9. Cost structure
[Needs more discussion]
2.2.9 REA (Resource-Event-Agent)
REA is a well-known financial abstraction of the operation of a business that is concerned with
the creation and exchange of value.
[The current version of VDML does not include mapping to REA, but this is planned for future
work.]
2.2.10
Metrics
The model supports the capture and analysis of metrics related to the performance of activities
and flows, and the assessment of values.
Metrics include the expression of specific measures as well as the computation of measures
incorporating specific measures. Thus metrics provide the mechanism for aggregation of
performance metrics or values from the measures associated with multiple activities in a value
chain. Metrics can also express variances with measures of average and standard deviation.
[Work is under way to align VDML metrics with the SMM specification.]
2.2.11
Extensibility
VDML defines a foundation for business analysis, but the specification cannot anticipate all of
the conceptual variations and associated properties that may be of interest in every industry.
Consequently, VDML includes an extension mechanism that allows users to define
specializations of the core VDML concepts and define additional properties of interest. These
extensions will be included if a VDML model is moved from one VDML tool to another.
Furthermore, it is anticipated that vendors and user groups will define sets of extension
definitions appropriate to specific industries, and these will be imported by VDML as shared
May 23, 2011
libraries. Shared libraries will improve the scope and usability of VDML and will improve
support for development of common practices and sharing of models between different user
organizations.
2.3 Model elements
This section specifies the details of the VDML metamodel. Note that many of these elements are
extensible. The specification and discussion of their extensibility is presented in a subsequent
section to minimize the complexity of the basic VDML metamodel specification and discussion.
2.3.1 Summary of Packages
The packages of the VDML metamodel are shown in the diagram, below.
May 23, 2011
VDML defines the business system (network, ecosystem) as a collaborative network, or network
of collaborations. Collaborations are defined in the package Collaborations.
A collaboration perspective provides the organizational structure and relationships for creating
and delivering (or exchanging) value. Values and assessment of values are defined in the
package Values. The Org Units package addresses the formal management organization
structure including ad hoc organizational units such as project teams and task forces. The
May 23, 2011
Capabilities package addresses the involvement of people, processes, intellectual capital,
facilities, equipment, etc., to perform a particular kind of work. The Value Chains package
addresses the involvement of capabilities in the performance of activities that produce value for a
product or service. The Business Relationships package addresses the participation of business
entities in a network of exchanges of value. Finally, the Communities package addresses the
relatively loose association of people and organizations in professional organizations, standards
organizations or other associations for which members have a common interest.
Various elements in the meta-model, such as capabilities, metrics, deliverables, etc., can be
standardized outside the scope of this specification, e.g. based on industry standard frameworks.
Companies can define their own internally standardized elements as well. Such elements are
contained in so-called libraries, which are defined in the package Libraries.
In VDML models, risk can be analyzed in association to model elements as risk sources, and
metrics that define risk impact. Risk-related elements are defined in the package Risk Factors.
The package Business Models supports the definition of business models from a stakeholder
perspective as configurations of business model building blocks and their relationships. Such
building blocks are freely-definable, to enable support of the various business modeling
approaches that do exist (e.g. Osterwalder’s approach). Business model building blocks and their
relationships can be mapped to other VDML elements, such as collaborations, value
propositions, metrics, etc., to provide rigor in business modeling, as well as to support high-level
representation of combinations of VMDL elements in ways that are meaningful to business
leaders and stakeholders.
2.3.2 Collaborations Package
This package contains elements that apply to any type of collaboration. A collaboration defines a
set of roles that collaborate for a particular purpose or to generate a specific value proposition or
outcome.
May 23, 2011
Actors, such as persons, can participate in roles. A collaboration as a unit may receive or provide
value to others through collaborations in which it participates. So a role of one kind of
collaboration can fill a role of another collaboration, such as an employee role in a company can
fill a manager role in a department. Role dependencies can also be defined, for example
participation in the employee role is a requirement for the participant to also fill the manager
role. Collaborations can participate in roles within other collaborations. For example, a contracts
team (a collaboration) participates in the Contract manager role on a larger Project Team (also a
collaboration).
When no participant is defined in a role, the role is said to be vacant.
Participants in roles within collaborations, can be said to provide value that contributes to the
collaboration. When participants, via roles, collaborate, each of them is providing value to others
through the roles that they play, and may receive value back in turn. Participants “contribute”
value, but also gain value “in return” as well. Values that roles provide can be defined through
value propositions.
Collaborations may have goals (or milestones) defined. Goals relate to deliverables.
The following picture provides an example (instance of meta-model) of how collaborations, roles
actors might relate.
May 23, 2011
In the diagram, ovals represent roles, rectangles represent collaborations and the rounded
rectangle represents an actor/person. The arrows indicate containment, so an arrow into a
collaboration indicates a role in the collaboration, and an arrow into a role indicates participation
in that role. Thus the Claims Processing Department is in a subordinate role of the XYZ
Company, and Fred is in an Employee role of XYZ Company, and as such is in a Claims Agent
role in the Claims Processing Department. As a Claims Agent he participates in a Quality
Reviewer role of the Work Team collaboration, and as a Quality Reviewer, he is in a Member
role of the Quality Committee collaboration.
In later sections, collaborations and roles will be specialized, to more explicitly fit different types
of collaborations.
2.3.2.1 Collaboration diagram
Defines the fundamental elements of collaborations.
2.3.2.1.1 Goal
Expresses a desired result of the collaboration as the completion of certain deliverables. May
also serve as a milestone by association with completion or receipt of a deliverable that satisfies
a goal. In other words, a milestone is achieved when certain deliverables are completed.
May 23, 2011
2.3.2.1.1.1 Attributes
2.3.2.1.1.2 Relationships
2.3.2.1.2 Participant
A participant is any actor, collaboration or role that participates in a collaboration. Participation
in collaborations is recursive such that any collaboration may have roles performed by actors,
other collaborations or other roles.
2.3.2.1.3 Role
A role defines the involvement of a participant in a collaboration, and it defines the
characteristics of the participant in the context of the collaboration. Note that a role may be
filled by another role, (for example a manager role can be filled by an employee role) and an
actor or role may be a participant in multiple roles and collaborations. So an employee (role in a
company) may participate in, e.g., a department collaboration (management hierarchy), a project
team collaboration and a professional community (also a collaboration).
Note below that a role of a collaboration may participate in one or more activities of a
collaboration.
2.3.2.1.4 Assignment
Assignment defines characteristics of the association between a role and a participant in the role.
For example, an assignment defines the beginning and end of a time period in which the
association of the specific participant is valid for the particular role. Assignment might be
restricted in other ways as well.
2.3.2.1.5 Actor
An actor is an individual participant that actually performs work and can assume roles.
May 23, 2011
2.3.2.1.6 Person
A person is a human actor whereas other actors might be machines, e.g. software agents,
autonomous vehicles, etc.
2.3.2.2 Activities diagram
Roles in collaborations may perform activities, which produce and consume deliverables.
Through their roles in a collaboration, participants can exchange value with each other or
produce an output for the collaboration by performing activities that receive and produce
deliverables.
May 23, 2011
May 23, 2011
Multiple views can be supported, based on activity network.
One of them is the Value Network view.
Input to
Strategy
Special
Projects
Trends
Executive
Team
Co brand
Opportunities
Resellers
Local
Strategic
Innovations
Marketing
Market
Focus
Company
Strategic
Ideas
Assess
Experiences
Offerings
Input to Direction
Market Cultural
Revenue
Strategy
Insights Trends
Insights
Insights
Trends
Input to
Strategy
Researchers
Product
Innovations
Market
Research
Beta
Tests
Revenue
Trends
Market
Assess
Technology
Company
Research Request
Market
Stories
Industry Co-branding
Experience Options
Advisory
Board
Local
Affiliates
Product
Suggestions
Plans
Selling
Insights
Strategic
Focus
Offerings
Trends
Revenue
Local
Marketing
Market
Market
Insights
Strategic Assess
Trends
Intelligence
Focus Offerings
Local
Company
Innovations
Trends
Contacts
Regional
Needs
Marketing
Go-To-Market
Innovations
Co brand
Partners
Opportunity
Market Insights
Feedback
The above diagram (courtesy of Verna Allee) focuses on the interactions of a technology
company with other communities of companies. It is essentially a view of the technology
company ecosystem. The diagram incorporates several different collaborations and identifies the
exchanges of values with these other communities. It provides an overall picture of the operation
of the technology company business and the exchanges of value that affect its success.
[The mapping of this view to more specific collaborations is non-trivial and is a current subject
of discussion for the VDML specification.
2.3.2.2.1 Activity
Work to be done to produce one or more deliverables. Generally an activity is presumed to add
value that will be evident in the deliverable(s).
May 23, 2011
2.3.2.2.2 Deliverable
A work product of an activity that may be delivered to another activity and thus indirectly from
one role to another through their activities.. A value cannot be delivered without a deliverable
that conveys it. A deliverable may be an actual product, an experience, a document or other
evidence that something has been transferred or made available.
2.3.2.2.3 Deliverable Flow
A deliverable flow represents the transfer of a deliverable from a provider activity to a
consuming activity. In some visualizations, the participant in the activity role may be expressed
with the activity elided.
2.3.2.2.4 Activity Port
An activity port represents the connection between an deliverable flow and an activity. This
allows for links within an activity to be associated with specific inputs and outputs that may
occur at different times during the performance of an activity. It also allows for specification of
the nature of the consumption of deliverables such as consumption of 4 wheels for one car where
computation of the cost of the car must include the cost of 4 wheels.
2.3.2.2.5 Goal
2.3.2.2.5.1 A goal defines a desired result that may be in terms of receipt or production of
deliverables. A collaboration may have multiple goals that are achieved by
different activities. Attributes
2.3.2.2.6 Activity Input Port
A port that receives a deliverable to an activity.
May 23, 2011
2.3.2.2.7 Activity Output Port
A port that issues a deliverable from an activity.
2.3.2.2.8 Directive
A management restriction or requirement for the performance of an activity.
2.3.2.2.9 Collaboration Interface
The interface through which an activity accesses a collaboration, potentially a capability that will
perform the work of the activity.
2.3.2.3 Paths diagram
As indicated in the value network diagram, above, accumulation of value contribution in value
networks, might require support by explicitly defined “paths”. This can best be understood when
thinking about “duration”. It makes a lot of difference whether one follows e.g. the “longest”
path or the “critical” path in a network. A “path” might also start and end at specific points, e.g.
starting with where the customer order comes in, until the point the product is delivered to the
customer.
May 23, 2011
2.3.2.3.1 Path
Identifies the activities and deliverable flows that form a path of interest.
2.3.2.4 Delegation diagram
Consider a business relationship (collaboration) between companies. The companies are
collaborations participating in a collaboration. The deliverables exchanged between the
participant companies are produced and consumed within each of the company collaborations.
Expanding the detail of each company, possibly multiple levels of collaborations, will expose
activities where work is actually performed to produce or consume the deliverables of the
business relationship exchange. Essentially the company “parent” collaborations delegate the
work to “child” collaborations that produce or consume the deliverables.
The participants in the business relationship are performing deliverable exchange activities in
their roles within the business relationship collaboration. A typical business relationship view
will not express all of the sub activities, but will focus on the participants and the deliverables or
values exchanged.
Deliverables from a “child” collaboration’s (participant’s) activity network(s) can be reconciled
with deliverables in the “parent” collaboration, by means of port delegations.
This way, value contribution accumulation (as carried by deliverables) can be considered the
result of traversing both “horizontal” delivery flows within both the “parent” and child
May 23, 2011
collaborations, and “vertical” port delegations between collaborations between parent and child
collaborations.
Note that some collaborations, such as a capability collaboration, may consume and provide
deliverables in multiple contexts. Conversely, a collaboration that delegates may engage
different collaborations at different times or under different circumstances, so the delegation
linkages are effectively a binding of collaborations to contributing collaborations.
May 23, 2011
2.3.2.4.1 Assignment
In this context, assignment defines the association between a role and a particular participant. As
such it provides the path of delegation from a role in one collaboration to a participating
collaboration. In this context, an assignment may be considered a specific binding of a parent
collaboration to a participant child collaboration.
2.3.2.4.2 Flow Delegation
Represents a deliverable flow into or out of a collaboration that is a flow into or out of an activity
within the collaboration. This provides the linkage between activities within a collaboration and
a role of the collaboration as a participant in a “parent” collaboration.
Flow delegation is semantically equivalent to delegation of two ports that are connected via a
deliverable flow. Rather than delegating both ports, it is sometimes useful to delegate the
deliverable flow itself. The delegated flow connects ports which might be contained in the same
“child” collaboration, but might also be contained in different “child” collaborations. In the latter
case, there is a “parent” collaboration (directly or indirectly), in which both “child”
collaborations participate in roles.
2.3.2.4.3 Port Delegation
Associates the input or output port of an activity in a parent collaboration with input and output
ports to which action is delegated in a child collaboration.
2.3.2.5 Collaboration Interface diagram
Collaborations may provide interfaces, through which they can provide services in multiple
collaboration contexts. Such collaborations are typically capabilities (though not necessarily).
May 23, 2011
When interfaces are provided, delegation of deliverables might go via ports of interfaces, rather
than via ports of activities directly. Internally in the “child” capability, interface ports might be
delegated (bound) to activity ports.
Interface ports aren’t associated with deliverable flows, as interfaces are meant to be usable in
multiple contexts (i.e. associated with activities in different activity networks, e.g. value chain
activity networks). The various activities that use the same interface, each consume and use their
own specific deliverables. An interface port can only define the type of deliverable (i.e. the
deliverable definition).
2.3.2.5.1 Interface Input Port
Links an input to a parent collaboration with the specific interface of a child collaboration.
2.3.2.5.2 Interface Output Port
Links the output of a child collaboration interface with a specific output of the parent
collaboration.
2.3.2.6 Intra Activity Deliverable Dependencies diagram
Activities might produce more than one output deliverable and might consume more than one
input deliverable. Not every input is required to produce every output, and production of certain
outputs might take longer than production of other outputs. Dependencies between inputs and
outputs inside (“intra”) an activity may be required to correctly calculate durations of value
creation and delivery through the network. Such dependencies are also the basis for defining
input requirements for the various outputs.
May 23, 2011
2.3.2.6.1 Intra Activity Deliverable Dependency
Links inputs of an activity to dependent outputs of the activity.
2.3.3 Values Package
Values are associated with deliverables. The flow of deliverables determines the delivery of
values.
For a product or service, a value proposition is used to represent the values delivered to a
recipient where these may be the result of contributions of value from multiple activities as well
as values associated with deliverables that are external inputs to those activities. A value
proposition may then represent the aggregation of the benefits (values) that a provider (providing
role) can deliver to recipients (receiving role) in a parent collaboration. A value proposition
element specifies the transformation from values of the provider activities to the provider’s
assessment of the level of satisfaction of the intended recipient.
May 23, 2011
2.3.3.1 Value Proposition diagram
The elements of this diagram provides for the aggregation of values from contributions of
multiple activities. The sources of value can be traced to contributing activities through the
chain of contributions.
The “process” of value creation (and delivery) can be followed based on deliverable flows,
possibly starting from a source deliverable, following various activities that transform them into
next deliverables, till the point a deliverable is produced which is of “value” to a recipient.
Contributions are essentially captured in a push-down list of Value Contribution elements.
Source deliverables, deliverable flows and activities may all contribute to value, and flow-based
accumulated value contributions can be carried by deliverables. A participants in an activity may
also be a collaboration that develops deliverables through flows and contributes these through
the activity that engages it. Often such value contributions can be expressed in terms of metrics
that are the result of aggregation from performance metrics of activities and deliverable flows
(cost, duration, quality measures, etc.).
May 23, 2011
The value contributions of activities form a list of value contributions representing accumulated
values to that point. This allows a resulting value to be traced to the source activities for that
value.
There may be a number of value propositions for a value network reflecting the different
interests of different recipients (e.g. different market segments or stakeholder groups). The level
of satisfaction of a recipient is determined by the transform formula, as part of a computed
metric (see further), for that value and market segment. This performs a transformation from an
“operational” metric - the measure of a value (contribution)- to a “value satisfaction” metric. A
“value satisfaction” metric might result in subjective values such as “excellent”, “good”, “fair”,
“poor”, “unacceptable”, but might also be stated in more objective terms, such as monetary
values. The satisfaction metric scale reflects the expected recipient’s satisfaction with the result,
dependent on the perspective from which the value proposition is defined.
Value ratings are combined into an overall proposition value (“satisfaction” level) based on the
value weights. The weight of each value will determine the degree of influence that its value has
on the overall rating for that stakeholder. Note that different stakeholders (i.e., different value
propositions) may have different priorities and thus assign each value a different weight.
2.3.3.1.1 Value Proposition
An element that provides a summary of relevant value contributions for a particular role,
collaboration or community (e.g., a market segment) along with a transformation of the
operational values to recipient satisfaction measures and a weighted overall value.
2.3.3.1.2 Value Proposition Value
Represents the weighted value of a particular type of value to the associated value proposition.
2.3.3.1.3 Value
Represents the aggregation of value contributions of a particular type of value as a basis for
computation of recipient satisfaction with that value.
May 23, 2011
2.3.3.1.4 Value Contribution
The contribution of a particular type of value by a particular activity in an activity network.
2.3.4 Org Units Package
An Org Unit involves a formally defined collaboration that forms a management hierarchy.
VDML users can define their own types of org units, as org units are defined as “extendable
element” (see further). Org units, dependent on user-defined “types” (or “org unit specs”), may
represent companies, departments, teams, task forces, etc.
2.3.4.1 Org Unit Roles diagram
Org Unit was introduced as a specialization of Collaboration, above. Collaboration roles are
specialized into org unit roles. While roles may be specialized through the extension
mechanism, roles specific to Org Unit are defined here to provide a consistent basis for
representation of business organizations.
The following matrix will express the use of these roles:
Participant
May participate in
Position
Employee
Leader
Subordinate
Responsibility Means
May 23, 2011
Employee
√
√
Position
√
√
Leader
√
Person (as
Actor)
Leader
√
√
Org Unit
√
Community
√
√
√
Capability
√
√
Value Chain
√
√
Value Chain
Role
√
Party
√
2.3.4.1.1 Position
A position is a formally defined role in an org unit. A position element without a participant is
allowed to represent multiple vacancies. An occupied position only represents the role of one
participant.
2.3.4.1.2 Employee
An employee role defines an employment relationship with an organization—i.e., a role in the
company. Generally, individuals who are employees will be represented in their employee role
when performing in other roles in an organization.
2.3.4.1.3 Leader
The leader role is that of the person in charge of the Org Unit, e.g., the manager, director, team
leader, etc. This is important for identification of the participant with primary responsibility.
May 23, 2011
2.3.4.1.4 Subordinate
The Subordinate role identifies a subordinate Org Unit. This is the role that defines the
traditional management hierarchy.
2.3.4.1.5 Responsibility
This role identifies other model elements that function as collaborations and are managed by the
Org Unit. This includes management responsibility for a value chain or a capability.
A capability or value chain defines an org unit responsibility for performing work that delivers
value. An organization unit may manage multiple capabilities that share resources and assets
supporting multiple activities.
2.3.4.1.6 Means
The means role identifies other model elements that function as collaborations and provide
mechanisms of operation.
2.3.5 Capabilities Package
A capability is a bundle of facilities, resources, assets, process(es), intellectual capital, and so on
that are managed together to perform a type of work. These characteristics are defined on a
Capability Definition. In performing work, an instance of a capability engages participants in
roles, and thus it functions as a collaboration. Capability is specialized from collaboration to
reflect organizational relationships and roles of participants in the performance of the capability
and the relationship of these roles to other collaborations. Generally, a capability is defined as a
participant in a responsibility role of an org unit that manages the capability.
2.3.5.1 Capability diagram
May 23, 2011
2.3.5.1.1 Capability
A capability is an instance of a Capability Definition. As such, it represents specific resources,
personnel, facilities, etc., possessed by the business organization to provide the capability.
2.3.5.2 Capability Roles diagram
There are several types of roles defined for capabilities.
May 23, 2011
The following matrix will express the purpose of these roles:
Participant
May participate in
Source
Capability
Component
Performer
Employee
√
Position
√
Leader
√
Member (of
Community)
√
Community
Leader
√
Org Unit
√
Community
√
Capability
√
Value Chain
√
Capability Means
√
√
√
Process
√
Case
√
May 23, 2011
√
Application
Machine
√
√
Note that processes, cases and applications, which can serve as means of capabilities, are
represented as collaborations of roles as well. These are defined in separate packages.
2.3.5.2.1 Source
Participants are sources of support for the capability as opposed to direct contributors to the
deliverable(s) of the capability. Financial services, IT services and purchasing services are
typical sources of support. These support or maintain the capability as opposed to participation
in the performance of the capability.
2.3.5.2.2 Capability Component
Participants are other capabilities that contribute to or participate in the delivery of the subject
capability.
2.3.5.2.3 Performer
Participants are direct contributors to the application of the capability.
2.3.5.2.4 Capability Means
Participants are mechanisms used to perform the capability such as business processes,
computer applications and machines. Value chains (“sub value chains”) can be defined as means
as well.
2.3.5.3 Machines diagram
May 23, 2011
2.3.5.3.1 Machine
Non-human actor, e.g. a software agent, or a piece of manufacturing equipment such as a lasercutting machine.
2.3.5.3.2 Decision Table
Can be modeled as actor, specialized from machine. Decision tables are subject of the potential
DMN specification.
2.3.5.4 Machines diagram
May 23, 2011
2.3.5.4.1 Machine
Non-human actor, e.g. a software agent, or a piece of manufacturing equipment such as a lasercutting machine.
2.3.5.4.2 Decision Table
Can be modeled as actor, specialized from machine. Decision tables are subject of the potential
DMN specification.
May 23, 2011
2.3.6 Processes Package
2.3.6.1 Process Roles diagram
2.3.6.1.1 Process Role
Represents a role in a business process that is viewed as a collaboration.
The following participants might participate in process roles: Employee, position, leader,
member, community leader, org unit, community, capability, process, case, application, machine.
May 23, 2011
2.3.7 Cases Package
2.3.7.1 Case Roles diagram
2.3.7.1.1 Case Role
Represents a role in a case management process that is viewed as a collaboration.
The following participants might participate in case roles: Employee, position, leader, member,
community leader, org unit, community, capability, process, case, application, machine.
May 23, 2011
2.3.8 Applications Package
2.3.8.1 Application Roles diagram
2.3.8.1.1 Application Role
Represents a role in a computer application that is viewed as a collaboration e.g. “buyer” role or
“Material Planner” role in a Procurement application)
The following participants might participate in application roles: Employee, position, leader,
member, community leader, org unit, community, capability, process, case, application, machine.
2.3.9 Value Chains Package
A value chain incorporates an activity network and identifies capabilities required and/or
provided to perform the activities. A value chain thus defines capability requirements and value
contributions for consideration of their impact and potential improvements to satisfy
May 23, 2011
stakeholders, typically customers/market segments, that receive value from the value chain
product or service.
The value chain thus defines the relationship between the collaborations (such as a line of
business) that manages the value chain, and the collaborations that manage the supporting
capabilities.
Participants in value chain activities are always capabilities. Capabilities may be implicit or
assumed in roles of collaborations of the various other types. They are explicit in value chains to
support capability analysis.
2.3.9.1 Value Chain Roles diagram
Value Chain is specialized from Collaboration and Value Chain Role is specialized from Role.
2.3.9.1.1 Value Chain Role
A value chain role defines the participation of a capability in a value chain activity. Only
capabilities can participate in value chain roles.
2.3.9.2 Value Chain Inventories diagram
The diagram, below, distinguishes value chain flows from other deliverable flows.
May 23, 2011
2.3.9.2.1 Value Chain Flow
A value chain flow is distinguished from other deliverable flows because it can have an
associated inventory that introduces time and cost factors into the value analysis. The inventory
may be an in-transit inventory.
2.3.9.2.2 Inventory
Inventory represents a buffer of deliverables waiting for consumption by the target activity of the
associated value chain flow. Inventories typically occur as a result of batch operations that
reduce the cost per unit of setup time. An implicit inventory may occur as a result of
deliverables in transit. Inventories may also incur cost for storage and investment, and
inventories may contain obsolete deliverables if the deliverable specifications change. An
inventory may shorten customer order delivery time by satisfying orders from stock rather than
production for individual orders, and int may introduce delay due to batch scheduling practices..
May 23, 2011
2.3.10
Business Relationships Package
Business relationships represent interactions between relatively independent business entities.
Business Relationship is specialized from Collaboration because the relationship involves
participants in roles that achieve mutual benefit.
2.3.10.1 Business Relationship Roles diagram
Roles in business relationships define how participants engage in collaborations and allow for
aggregation to larger scope relationships.
Participant
May participate in
Party
Component
May 23, 2011
Org Unit
√
Subordinate
√
Person
√
Community
√
Subset
√
Business Relationship
√
2.3.10.1.1 Party
A party in a business relationship is a participant that provides and receives values from other
participants.
2.3.10.1.2 Component
A component in a business relationship defines the detail of a segment of the parent business
relationship. The component business relationships are like pieces in a puzzle rather than
abstractions of detail. Thus a large scope business relationship may include many more specific
business relationships associated with different product and services. The parent business
relationship view may consolidate the roles of the same participant in different child business
relationship so to that extent it provides a higher level abstraction.
2.3.11
Communities Package
A community is a loose association of participants with a common interest. The community may
or may not involve explicit interactions between to participants or contributions to a common
purpose. This minimal association is typical of customers in a market segment. Together they
may influence the market, but they are generally not interacting directly with each other.
2.3.11.1 Community Roles diagram
A specialized set of roles is defined for the loose association in a community.
May 23, 2011
Participant
May participate in
Member
Community
Leader
Employee
√
√
Person
√
√
Position
√
√
Leader
√
√
Member (of
Community)
√
√
Community
Leader
√
√
Org Unit
√
Community
Subset
Community
Responsibility
Community
Means
√
√
√
Capability
√
√
Value Chain
√
√
Value Chain
Role
√
2.3.11.1.1 Community Role
This is an abstract specialization of Role for roles associated with a community.
May 23, 2011
2.3.11.1.2 Member
A member is a participant in a community that shares the common interest. Membership may be
explicit or implied (as for a market segment), so member roles are not required.
2.3.11.1.3 Community Leader
Generally a community will have a participant that has leadership responsibilities that distinguish
it from other members.
2.3.11.1.4 Subset
A community may have subordinate communities that bring together a subset of its members for
a more specific purpose or interest.
2.3.11.1.5 Community Responsibility
A community may have structured activities (capabilities or value chains) by which it produces
value for members, for the community as a whole or for other entities that have an interest in the
activities of the community. A community of environmentalists provide value to society as a
whole (another, larger community).
2.3.11.1.6 Community Means
Through capabilities, a community may have processes and applications that support its
activities.
May 23, 2011
2.3.12
Metrics
Metrics express measures and computations of measures that support the analysis of business
operations and the expression of measures of values.
[Work is under way to harmonize these metrics with the SMM metamodel]
2.3.12.1 Metrics Package diagram
2.3.12.1.1 Metric
Metric is the common super-type of more specific metrics. All metrics have a unit of measure, a
metric definition, and a result.
May 23, 2011
2.3.12.1.2 Result
The result is an actual measure that may be the result of an observation (or input) or the result of
a computation.
2.3.12.1.3 Primitive Metric
A primitive metric is an numeric value.
2.3.12.1.4 Qualitative Metric
A qualitative metric is expressed as a descriptive expression. This is used, for example, to
express qualitative value measures as well as levels of customer satisfaction in a value
proposition.
2.3.12.1.5 Computed Metric
A computed metric determines a result by application of an expression (typically a query or
formula) to results of other metrics. It may also compute a standard deviation for its result based
on the variance of supporting data.
2.3.12.1.6 Lookup Data
Provides an expression for retrieval of relevant data and may be used to support e.g. non-linear
calculations (e.g. several functions in spreadsheets require this).
May 23, 2011
2.3.12.1.7 Descriptive Result
A result that contains a descriptive value that is one of the associated descriptive value
enumeration elements.
2.3.12.1.8 Descriptive Value Enumeration
One of a set of possible descriptive values associated with a metric.
2.3.12.1.9 Numeric Result
Note how computed metrics can be aggregated from metrics.
2.3.13
Business Models Package
A business model is an abstraction of a business/enterprise that expresses the fundamental
operation of the business from a stakeholder perspective. There are several types of business
model that involve relationships between “business model building blocks.” This specification
does not adopt a particular type, but defines a set of elements that can be extended for
representation of the building blocks of a particular type as determined by the VDML user.
2.3.13.1 Business Modelsdiagram
The diagram below defines the generic elements that can be specialized to represent the building
blocks of a particular type of business model. Each of these is extensible to represent the
elements of a particular type of business model.
May 23, 2011
2.3.13.1.1 Business Model
A business model element represents a particular instance of a business model that contains
building blocks and relationships.
2.3.13.1.2 Business Model Relationship
Represents a relationship between building blocks
2.3.13.1.3 Business Model Building Block
Represents a business model building block.
May 23, 2011
2.3.13.2 Business Model Implementation diagram
These elements support mapping to other, more specific VDML elements, to define the business
model in more detail and with more rigor
2.3.14
Libraries Package
The dictionary contains definitions of extended element types that are categorized in a directory
structure.
2.3.14.1 Library diagram
The diagram, below, defines the general structure of the lobrary. Subsequent diagrams define
library elements for specific categories of definitions.
May 23, 2011
2.3.14.1.1 Library
The root of the dictionary directory structure.
2.3.14.1.2 Metric Definition
In this context, standardized metrics associated with a capability definition.
May 23, 2011
2.3.14.1.3 Value Definition
In this context, standardized values associated with a capability definition.
2.3.14.1.4 Capability Tree Node
Elements that define a capability directory hierarchy
2.3.14.1.5 Capability Group
A library for a category of capabilities
2.3.14.1.6 Capability Definition
An element that defines a capability type and may be located in the capability library.
2.3.14.1.7 Capability Dependency
An association of capabilities that defines the dependency of a capability on one or more other
capabilities.
2.3.14.1.8 Deliverable Definition
In this context, standardized deliverables associated with a capability definition.
May 23, 2011
2.3.14.1.9 Practice Definition
In this context, practices associated with a capability definition.
2.3.14.1.10
Technology Definition
In this context, technology associated with a practice definition.
2.3.14.2 Metric Definition diagram
The following diagram specifies the details of metric definitions
May 23, 2011
2.3.14.2.1 Metric Definition
A metric definition specifies a type of metric.
2.3.14.2.2 Dimension
The type of dimension represented such as distance, volume, time, weight, etc.
May 23, 2011
2.3.14.2.3 Unit of Measure
Specification of the unit of measure used such as feet, kilograms, Euros, etc.
2.3.14.2.4 Benchmark
An expected measure for the metric.
2.3.14.2.5 Benchmark Element
2.3.14.2.6 Benchmark Kind
2.3.14.2.7 Metric Type System
2.3.14.2.8 Scale of measurement
2.3.14.3 Deliverable Definition Category diagram
The following diagram depicts the dictionary elements for categorization of deliverable
definitions.
May 23, 2011
2.3.14.4 Metric Definition Category diagram
The following diagram depicts the library elements for categorization of metric definitions.
May 23, 2011
2.3.14.5 Value Definition Category diagram
The following diagram depicts the library elements for categorization of value definitions.
May 23, 2011
2.3.14.6 Practice Definition Category diagram
The following diagram depicts the dictionary elements for categorization of practice definitions.
May 23, 2011
2.3.14.7 Technology Definition Category diagram
The following diagram depicts the library elements for categorization of technology definitions.
May 23, 2011
2.3.15
Risk Factors Package
Value exchanges and, particularly, value chains identify actions that must occur to sustain the
normal course of business. This provides an opportunity to identify the risks associated with
disruption of critical links. The risk factor package provides for the definition of disruptive
scenarios and the links that could be adversely affected.
2.3.15.1 Risk Factor diagram
The diagram below identifies the core metamodel elements for modeling risks. These are
specialized using the extension mechanism to address more specific categories of risk.
May 23, 2011
2.3.15.1.1 Risk Scenario
This identifies a business situation that could be disruptive. It could be an economic event or
trend, natural disaster, political disruption, product defects or other loss of availability of key
resources or capabilities. The present value of associated risks can be determined using the
probability of occurrence of the scenario.
2.3.15.1.2 Risk Factor
Identifies specific risks that would result from a risk scenario.
2.3.15.1.3 Risk Factor Dependency
The occurrence of a risk factor may have a propagation effect that results in the occurrence of
other risk factors.
May 23, 2011
2.4 Extension Definitions
VDML incorporates a consistent extension mechanism. This section begins with a specification
of the basic structure. Subsequent sections define the application of this pattern to the various
extensible elements of VDML. While these applications are part of the specifications discussed
earlier, they are described in this separate section to minimize the complexity of the basic,
VDML model discussions.
2.4.1.1 Extension Definition diagram
The following diagram defines the basic concepts of the extension mechanism. All extensible
elements inherit from Extendable Element and thus have both an Extension Definition and
potential Extension Property(s).
May 23, 2011
2.4.1.1.1 Extendable Element
A super type of an element that is extensible, meaning that its type can be specialized.
2.4.1.1.2 Extension Definition
The specification of the type of an element defined using the extension mechanism. The type
defines constraints and properties. Extension definitions can be further specialized to one or
more sub-types, recursively.
May 23, 2011
2.4.1.1.3 Expression
A conditional expression that restricts the attributes and/or relationships of the extended type.
2.4.1.1.4 Extension Property
A property added by a user to an extended element.
2.4.1.1.5 Extension Property Definition
The specification of a property type that is added by the user to a type of extended element.
2.4.1.1.6 Enumeration
A set of possible values of a property if applicable.
2.4.1.1.7 Enumeration Value
A specific value of a set of possible values.
2.4.1.2 Additional Reference-able Elements diagram
May 23, 2011
2.4.2 Collaboration Extensions
Xxx
May 23, 2011
2.4.3 Value Proposition Extensions
Xxx
May 23, 2011
2.4.4 Org Unit Extensions
Xxx
2.4.5 Capability Extensions
May 23, 2011
Xxx
2.4.6 Machine Extensions
May 23, 2011
2.4.7 Process Extensions
2.4.8 Case Extensions
May 23, 2011
2.4.9 Application Extensions
2.4.10
Value Chain Extensions
Xxx
May 23, 2011
2.4.11
Business Relationship Extensions
Xxx
2.4.12
Community Extensions
Xxx
May 23, 2011
2.4.13
Metric Extensions
Xxx
2.4.14
Business Model Extensions
Xxx
2.4.15
Library Extensions
May 23, 2011
Xxx
2.4.16
Risk Factor Extensions
Xxx
May 23, 2011
3 Appendices
3.1 References (non-normative)
These references are provided as additional information on related approaches and the concepts
incorporated in this specification. They are not a normative part of this specification.
Michael Porter, Competitive Advantage: Creating and Sustaining Superior Performance, The
Free Press, New York, 1985.
Thompson, J.D., Organizations in Action, McGraw-Hill, New York, 1967.
Stabell, C.B., and Fjeldstad, O.D., Configuring Value for Competitive Advantage: On Chains,
Shops and Networks, Strategic Management Journal, 19(5), 413-417, 1998. (See
http://www.agbuscenter.ifas.ufl.edu/5188/miscellaneous/configuring_value.pdf )
Value Chain, Wikipedia, http://en.wikipedia.org/wiki/Value_chain
Jaap Gordijn and Hans Akkermans. Value based requirements engineering: Exploring innovative
e-commerce idea. In /Requirements Engineering Journal/, Vol. 8(2):114-134, 2003. Discussion
of the e3Value model: http://e3value.few.vu.nl/docs/bibtex/pdf/Gordijn2003e3value.pdf and a
popular version of it: http://e3value.few.vu.nl/docs/bibtex/pdf/Gordijn2001e3value.pdf
Yves Pigneur. An ontology for defining e-business models. Université de Lausanne, 2004,
describes another e-business model with clear differentiation between process / capabilities and
value delivery http://www.hec.unil.ch/yp/TALK/slides/UBC_Jan2004.ppt#10
Mike Rother and John Shook. Learning to See. Lean Enterprise Institute, 1998, discusses the
Value Stream Mapping (VSM) methodology of www.lean.org and illustrates the concept behind
value delivery analysis.
Dan Jones and Jim Womack. Seeing the Whole. Lean Enterprise Institute, March 2003, See an
on-line chapter in http://www.lean.org/Library/Seeing_the_Whole_Part1.pdf
Cummins, Fred A., Building the Agile Enterprise with SOA, BPM and MBM, Morgan Kaufman,
2009.
Harmon, Paul, Business Process Change: A Guide for Business Managers and BPM and Six
Sigma Professionals, Morgan Kaufman, 2007.
Component Business Modeling, IBM,
http://www.haifa.ibm.com/projects/software/cbm/index.html .
Francis, Joseph, The IT Supply-Chain SCORcard, BPTrends,
http://www.bptrends.com/publicationfiles/NINE-03-07-COL-ITSupplyChainSCORcardManaging%20BPM-Francis-Final.pdf
May 23, 2011
Youxu Tjader, et al, Integrating the Analytic Network process and the Balanced Scorecard for
strategic IT Outsourcing Decision Making,
http://www.creativedecisions.net/~rozann/0Proceedings/Final_Papers/86_Tjader_Shang_Vargas
_May_ANP_BalancedScorecard_for_ITDecisions_REV_FIN.pdf
Donaldson, Krista M., Kosuke Ishii, Sheri D. Sheppard, Customer Value Chain Analysis,
http://www.stanford.edu/~kmd/Donaldson2006CVCA.pdf
Allee, Verna, Value Networks and the True Nature of Collaboration, ValueNet Works, 2011,
http://www.valuenetworksandcollaboration.com.
Allee, Verna, A Value Network Approach for Modeling and Measuring Intangibles,
http://www.vernaallee.com/value_networks/A_ValueNetwork_Approach.pdf
Allee, Verna, Value Network Analysis and Value Conversion of Tangible and Intangible Assets,
http://valuenetworks.com/docs/Value_Conversion_JIC_online_version_final_draft.pdf
Dumez, Herve and Jeunemaitre, Alain, The Management of Organizational Boundaries: A Case
Study, at www.cairn.info/revue-management-2010-3-page-152.htm
3.2 Glossary (non-normative)
[The Glossary is still under construction]
Activity. An activity represents work required to transform input deliverables to output
deliverables.
Business model. A business model describes the rationale of how an organization creates,
delivers, and captures value . A Business Model (BM) serves as a building platform that
represents a company’s operational and physical manifestation (Source: ICI)
Capability. A bundle of facilities, resources, assets, process(es), intellectual capital, etc., that are
managed together to enable the performance of a type of work.The model provides for
standardized capability definitions and capabilities that are instances of capability definitions—
the actual elements owned by or engaged by an organization that is responsible for the required
work (and are, together, modeled as a collaboration). An activity references a capability
definition to express capability requirements and to enforce standardization in the business
network, and engages a capability as the actual source of work. The implementation of a
capability may in fact involve the engagement of other capabilities that are not visible to the
value chain activity.
Value. A measurable aspect of a business or one or more of its deliverables, subject to
appreciation by its recipient stakeholders Also: A potential or realized benefit associated with
some action or thing
May 23, 2011
Value proposition. A value proposition is the set of values provided or intended to be provided
to a recipient. Some of the values may be intrinsic in a product and other values may be
provided in other ways such as the enterprise reputation or timely response.
The values of the value proposition may be traced back to activities that contribute to that value
so that they may be considered to be maintained or improved.
Deliverable Flow. A deliverable flow represents the requirement for input to an activity that is
satisfied by the output of another activity. Generally, this represents the transfer of some form of
work product or deliverable from the participant in the role performing the work of one activity
to the participant in the role performing the work of another activity.
Line of business. A line of business is interpreted as a segment of a business that can be
represented by a single value chain. The line of business may be a division of a large enterprise
or a particular product or service that has distinct requirements for capabilities and the
dependencies between them. The line of business represents organizational responsibility for the
delivery of customer value for the associated product or service. The scope of a value chain, and
thus the scope of a line of business will be determined by the modeler, but generally should be
the basis for a value chain where most of the same activities are required for delivery of
variations in the product or service.
3.3 Library (normative)
The library will contain normative extensions to the extensible elements. These are to be
implemented as extensions so that operations on the model can be consistent for both normative
elements and user-defined elements. They are normative so that implementations can rely on
them in defining analytical functions and other product features, and so that they can be more
easily integrated with other models with shared tools.
[It is not clear at this time if these library specifications will be included in the VDML
specification or left to other standards efforts.]
3.4 Related OMG specifications (normative)
There are no changes to related OMG specifications. The following are specifications that have
logical relationships to VDML.
BMM (Business Motivation Model)
BPMN (Business Process Model and Notation)
SoaML (SOA Modeling Language
SMM (Software Metrics Metamodel)
May 23, 2011
3.5 Notation Examples (non-normative)
The following diagram suggest via which views the various elements of VMDL can be
defined, and how these views may depend on each other.
Mockups for views identified as 1 – 6, are included below. A appropriate view to support
for value assessment (7) is still under discussion.
Additonal views will be added later, such as to support:
•
•
Risk assessment
Business model representation
An implementation will also need to provide additional support for where-used, comparisons,
etc.
A collaboration view (1) can be envisaged as indicated in the next picture.
May 23, 2011
This view has some look-and-feel similarity with Conversation view in BPMN 2.0. The octagons
represent collaborations, the circles represent collaboration activities with roles (or participants,
via their roles). B participates as a buyer in one collaboration (with A) and as a seller in the other
collaboration (with C). The collaboration view is adequate to overview the broader ecosystem of
multiple related collaborations, intra- and inter enterprise.
When octagons (collaborations) in this view are expanded, the result may look like the so-called
value network view (3), which shows the deliverable flows between the roles in the
collaborations.
In this view, roles are highlighted, and activities (that consume and produce deliverables) are
hidden.
May 23, 2011
Alternatively, activity network views (4) can be used, as represented below, that are supported
by the same meta-model, but that highlight the activities. Roles can be represented as swim-lanes
(not visible in this example).
Several variations of the activity network will be useful.
Inventories can be placed on deliverable flows, such as suggested by the following view.
It would also be useful to map the activity network on a horizontal time-line, like in
PERT or Gantt chart view. In such a view horizontal distance between activity shapes
as well as horizontal length of activity shape indicate duration.
It might possibly be useful to use alternative activity shapes, such as typical “porter”
shapes, to highlight the different purpose of VDML activity networks, as opposed to
BPMN activity networks.
Above we suggested an “activity discovery view” (2), which is useful to start defining
goals of collaborations, and activities to achieve goals. The following picture
provides a draft impression of such a view.
May 23, 2011
Note that more variation is useful, to support e.g. goal-decomposition, possibly also a
combination with horizontal lanes for roles). Capability definitions, from a library,
miht be dragged into this view, to start the creation of activies (hende “activity
discovery view”).
So-far all views (1-4) related to expression interaction and flow within a collaboration
(“horizontal”). The following views address aspects how “participation”, how actors,
roles or collaborations participate in roles of collaborations (“vertical”).
The following view (5) adopts the paradigm of an org chart, but can apply to more
collaborations than just org units
May 23, 2011
In order to define for a particular participant, in which roles it participates, a network view (6)
might be useful, as presented in the following picture.
3.6 Supporting Examples (non-normative)
TBD
May 23, 2011

Value Delivery Modeling Language (VDML)

Transcription

Similar documents

2016- 2018 Strategic Plan LAKE COUNTY YMCA

Data Science - SourceMedia

Visure Requirements

LSDF Grant Semi-annual Progress Report Overview

What is SQDC*? How do I implement SQDC** in my area? Step 1

Team Offense Instruction and 3 on 3 Games Free Reversible Jersey

Jongert Trewes 67 GODEN WIND

Kitchen Designs Standard Specification

Software development

Value Delivery Modeling Language (VDML)