VDML for Business Architects: Part 1 of 11, Introduction

The OMG (Object Management Group) issued an RFP for a Business Architecture Core Metamodel (BACM) in March, 2017. The purpose of this RFP is to obtain a modeling language for business architects to support business leaders in the development of strategic business plans and transformation models.  The modeling language will ensure that the multiple perspectives for a strategic plan are integrated to ensure a consensus on a consistent and validated transformation plan.  The RFP can be found at https://www.omg.org/cgi-bin/doc?bmi/17-03-07 .

The reference to a “core metamodel” reflects the intent to provide a metamodel (modeling language specification) that captures and integrates the key elements of existing diagrams and tables used by business architects to describe strategic solutions.  This integration will ensure the consistency of the various perspectives and associated displays for rapid configuration, validation and development of consensus on business transformation solutions.  The RFP does not call for specification of displays since an integrated modeling capability will enable enhanced views that will be refined as business architect practices continue to evolve.  The VDML specification can be found at https://www.omg.org/spec/VDML/

Three draft specification proposals were submitted to OMG in May, 2018. One of those submissions is based on VDML (Value Delivery Modeling Language), an existing OMG specification, adopted in May, 2015.  The BACM submission proposes some extensions to VDML to improve support of strategic planning and transformation management. The current VDML specification can be found at https://www.omg.org/spec/VDML/ .

VDML was developed to address the modeling needs of business leaders, such as

·         Abstraction to represent a business design at an appropriate level of detail for business leaders,
·         Identification of the sources and consequences of value contributions for customers,
·         Recognition of the many ways that people participate in doing the work of the enterprise,
·         Support for analysis of potential improvements and the impact of innovations,
·         Analysis of the interactions with customers, business partners and other members of the business ecosystem, and
·         Rapid exploration of potential business changes and optimization of operations across lines of business.

While providing a powerful modeling capability for business analysis and design, the version of VDML adopted by OMG falls short of support for strategic planning and business transformation as required by the Business Architecture Core Metamodel (BACM) RFP.  The VDML-based submission to the BACM RFP is named Business Architecture VDML Extension (BAVE) and includes extensions to address strategic planning and business transformation. 

The result is an integrated modeling capability that fills the gap between strategic planning and conceptual business design that ensures a clear, shared understanding for implementation of transformation requirements as well as analysis, monitoring and incremental improvement of business operations.
 The BAVE submission to the BACM RFP demonstrates VDML support for most of the business architecture perspectives and provides some extensions to address innovation, strategic planning and transformation shortcomings.  The submission illustrates how subsets of the metamodel support the following perspectives:

·         Organization
·         Capability
·         Process
·         Value
·         Scenario
·         Measurements
·         Business partners and customers
·         Products and services
·         Information and data
·         Regulations, policies and rules
·         Objectives and transformation planning

These perspectives will support various diagrams currently used by business architects.  However, the integrated model will also support evolving business architect practices and future diagrams enabled by VDML integration of these different perspectives.  The integrated metamodel also brings together the key VDML modeling features that I will describe in subsequent posts.

The subsequent ten posts on this topic, VDML for Business Architects, will describe features that distinguish the extended VDML as a robust modeling language for business planning, analysis and design by business people and, in particular, by business architects.  Most of these features are included in the current version of VDML.  The features are presented in the following categories:

·         General features
·         Organization
·         Capability modeling
·         Process abstraction
·         Measurements
·         Accountability
·         Value contribution analysis
·         Executive dashboard support
·         Agile business architecture
·         Business transformation

Features based on the proposed BAVE extensions are identified in Parts 7, 10 and 11. 

For more abut business modeling and VDML, see my book, Building the Agile Enterprise with Capabilities, Collaborations and Values.

VDML for Business Architects: Part 2 of 11, General Features

Please see the post for VDML for Business Architects: Part 1 of 11, for the introduction to this series of posts.  This post describes general features of VDML that help fill the gap between strategic plans and realization of appropriate business transformation.
1.    Round-Trip design modeling

Executives can develop a high-level model of a transformed enterprise to pursue a strategic objective.  However, in order to validate and realize a strategic objective, it is necessary to develop a more detailed business model to ensure that the solution is feasible and beneficial, and that it can be implemented appropriately at a more detailed level. 

VDML supports the executive model and the structure for expansion of the design to an appropriate level for implementation requirements.  In addition, since VDML provides a consistent model from executive vision to operational requirements, there is a seamless expansion of the executive model.
If  the executive model is defined in a different, more abstract tool, the model will be imported to VDML for the development of detail.   Additional modeling detail will likely reveal needs to revise the strategic plan for feasibility or efficiency.  The revised model will be returned to the executive tool for approval or additional revisions. However, if the executive modeling tool is independent of VDML, then details will be lost returning to the executive tool, and further executive revisions will then make the executive model inconsistent with the VDML detail thus resulting in repeated work.
2.    Single, seamlessly integrated model

VDML represents the design and operation of an enterprise and its ecosystem as a single, seamlessly integrated model as opposed to a composite of linked models that represent different aspects of an enterprise.  The single model minimizes complexity and ensures consistency without human effort to reconcile different viewpoints. 

All the displays that could be supported by separate models can be implemented as views on the seamless model assuming the separate models have consistent concepts.  In addition, the seamless model will more easily support views that bring together multiple aspects of the enterprise.  For example, one current implementation of VDML supports a Business Model display (e.g., Osterwalder or Lindgren) with multiple business perspectives that are integrated and consistent through the underlying VDML model.   In the long term, the seamless model will lead to more and better views and methods for developing and analyzing a model, and it will support further advances in enterprise modeling and associated practices.
3.    Incremental business design

A VDML model can be developed top-down, selectively expanding delegation with deferred activity details to the extent acceptable for executive consideration.  Alternatively, a model can be developed by examination of current business operations to identify capabilities and activity networks to the extent necessary to support current analysis and performance improvement, and to reconcile current operations with transformation plans.

4.    Scenarios

A scenario defines a set of measurements and a capability method delegation tree for a particular business situation.  This supports rapid analysis of differences in operating variables.  Different measurements and configurations can be applied to the same model in different scenarios for exploration of what-if solutions.  Measurements can be attached to any MeasurableElement of VDML for each scenario and computed for propagation of effects such as customer value.

5.    Support for system dynamics modeling

The statistical flow and value contribution design of VDML models (see Part 6) provides the basis for future development of system dynamics (simulation) models of enterprise operations.  Such models would be valuable for consideration of resource requirements, costs and delays involving Stores (a network element where units of production are held pending action by a receiving Activity) and Pools (a Store that holds reusable resources pending assignment by receiving Activity) along with business partner and market effects of changes in value propositions.

6.    Technology-independent abstraction

The VDML abstraction is IT technology-independent except as the technology applied affects the speed, efficiency or quality of business operations.  A VDML model represents enterprise design and operations without reference to the complexity of the technology(s) involved in the implementation.  This extends to modeling of interactions with outsourcing providers and other business partners, thus including the enterprise ecosystem.

7.    Business process and activities abstraction

Capability methods represent abstractions of conventional business processes but with statistical flow measurements.  These abstractions are much less complex than conventional business process models and are more compatible with the interests of executives (see also Part 5).

8.    Computer-generated process design framework

Activity networks can be translated to business process models that provide a framework for the more detailed design of flow-control-based process models.  This framework can provide alignment of VDML, abstract activity networks with operational business process models for shared performance and value measurements.

VDML for Business Architects: Part 3 of 11, Organization

Please see the post for VDML for Business Architects: Part 1 of 11, for the introduction to this series of posts.  This part focuses on collaboration as a fundamental organizational concept for more robust modeling of the structure, operations and relationships of people and organizations to achieve enterprise objectives.
1.    Collaboration as how all work gets done

Collaboration is the fundamental concept for how work of an organization gets coordinated and accomplished.  Any collaboration can receive inputs, produce outputs and contribute to values. Collaborations include all forms of persons and/or other collaborations working together for a shared purpose.  Collaborations are specialized to four sub-classes: OrgUnit (organization), BusinessNetwork, Community and CapabilityMethod (process abstraction). 

2.    Organization structure

An organization hierarchy is composed of nested OrgUnit collaborations with Position roles, including roles for unit leader/manager and sub-organizations.  OrgUnits, in general, have responsibility for resources in Stores (consumable resources) and Pools (reusable resources including personnel). 

3.    Collaborations as a core building block

A collaboration has Participant roles that do the work of the collaboration.  A role may be filled by another role such as an OrgUnit Position, or a collaboration (as a Performer) representing delegation of one collaboration to another (most often a capability method delegates to an OrgUnit that performs another capability method).  These capability methods can be implemented as sharable services that contribute to multiple value streams and lines of business.

4.    Context-based role assignments

Scenario-based contexts enable some capability methods to be engaged in different contexts including other value streams and lines of business.  The measurements and role assignments will be different in different contexts.  Performance measures may depend on different work products and facilities. Roles of the capability method may draw on personnel resources of different organizations.

5.    Roles of roles

Roles can be filled by roles.  This enables, for example, roles of an OrgUnit to fill roles of a capability method or roles of another collaboration such as a project team or a committee.  Roles may represent personnel in a Pool for assignment to roles in other collaborations.

6.    Extended organizational relationships

Traditional organization models focus on the management hierarchy with weak recognition of other relationships that are essential to the operation of the business.  VDML provides for integrated modeling of the many cross-organization collaborations and multiple roles of employees to identify the multiple contributions and relationships of employees in additional collaborations.

7.    Organizational change impact analysis

Cross-organizational role assignments highlight less obvious organizational contributions and dependencies.  These are important relationships to understand when changing organizational assignments.

8.    Shared personnel/resources

VDML can represent personnel and resources shared across organizations for resource sharing and workload balancing.

VDML for Business Architects: Part 4 of 11, Capability Modeling

Please see the post for VDML for Business Architects: Part 1 of 11, for the introduction to this series of posts.  This part focuses on business capabilities and their application to accomplish required work.  A capability is the ability to perform the type of work to deliver desired results.  It includes personnel with required skills, facilities, access to resources and the intellectual capital for reliable and efficient capability application.
1.    Capability applied by individuals and/or collaborations

A capability method is a combination of collaboration and capability that specifies the application of a capability including the activities performed by individuals or delegated to organization units that apply other, supporting capability methods.

2.    Capability delegation network

Delegations from a capability method to other capability methods form a delegation tree that may be modeled without the detail of activities that engage the delegated capability methods.  Value contributions of capability methods (or other collaborations) can be manually specified without activity network details.  The delegation tree is not only important for specification of shared services, but it supports refinement of the scope of capabilities and it provides the basis for assignment of capability resources and responsibilities to organization units.

3.    Capability methods as building blocks

Capability Methods can represent sharable services in a service-oriented architecture.  This supports capability methods as shared components for configuration of new business models that leverage existing capabilities.  It also achieves economies of scale in the development of methods and personnel as well as utilization of resources and adaptation to changing business requirements.

4.    Capability library links to capability implementers, providers and applications

The capability library is a taxonomy of all capabilities of the enterprise.  These have links to the organization units that have implementation and/or application responsibility and the activities that engage capability method(s) that deliver the capability in different value streams and lines of business.  The taxonomy is a classification hierarchy.  This is not the same as a delegation tree that depicts levels of engagement of capability methods.

5.    Selective expansion of capability delegation

Capability method delegations form a tree of capability methods.  These delegation trees with activity networks may be selectively expanded as appropriate to the level of delegation necessary for the accuracy required by the purpose of the model.  An un-expanded capability method can provide an estimated summary of value contributions of the un-expanded branch of the delegation tree.

VDML for Business Architects: Part 5 of 11, Process Abstraction

Please see the post for VDML for Business Architects: Part 1 of 11, for the introduction to this series of posts.  VDML represents an abstraction of a business process as a capability method with an activity network representing particular operations. The activity networks do not require the technical details encountered in operational business process models.

1.    Unit of production flow model

Instead of specification of flows of individual business transactions, VDML represents the statistical flow of a unit of production.  While there may be different flows through an activity network, these flows are described as fractions of a unit of production and they impact value contributions according to those fractions. This abstraction is less complex and more consistent with business leader concerns and mental model of processes.

2.    Context-based role assignments

Capability methods can be engaged in multiple contexts within the same VDML scenario (e.g., different lines of business). These capability methods may be managed by different organization units such that there are different role assignments by the different organization units.

3.    Performers as business objects/deliverables

Role participants can be passed by delegation and/or be used as deliverables in activity networks.  For example, a patient may be an activity performer and also be the subject (i.e., work product) of activity operations.

4.    Asynchronous/buffered deliverable flows

Where business process models send messages for asynchronous exchanges, VDML sends deliverables to Stores that function as buffers or queues.  A store may have measurements of the number of deliverables waiting and the time a deliverable is delayed in the store.

5.    Inputs and outputs of collaborations and activities

Various subject matter such as products, documents, resources, materials and communications are the inputs and outputs of collaborations, activities, stores and pools.  VDML identifies all of these as “business items” that are classified, described and named in the BusinessItemLibrary.  The physical nature of these business items is generally unimportant in the VDML abstraction except as their nature affects the measurements of the performance and value contributions of the collaborations and activities that consume and produce them.  The classifications and descriptive names are meaningful for model developers and users to understand what the collaborations and activities are doing and exchanging.

6.    Resource/personnel requirements analysis

Resource and personnel requirements can be computed from consumption by assigned activities, production rates and duration of assignments (from Pools of reusable resources and personnel). 

VDML for Business Architects: Part 6 of 11, Measurements

Please see the post for VDML for Business Architects: Part 1 of 11, for the introduction to this series of posts.  This part is focused on the implementation of measurements supported by integration of the Structured Metrics Metamodel specification (OMG).
1.    Statistical measurements

VDML measurements are statistical rather than measurements of individual transactions or operations.  This eliminates much of the complexity of flow control in business process models and is better suited to executive mental models and decision-making.  A measurement may be an average or parameters of a statistical distribution as appropriate to support a desired level of analysis.

2.    Context-based measurements

Measurements are in the context of a selected scenario, as noted in Part 2.  However, a collaboration (capability method) may be applied in different contexts—different activity networks and/or different delivery organizations.  These measurements are determined by the particular context in which the capability method is applied.

3.    Rapid evaluation of measurement adjustments

Changes to business design or performance measurements can be immediately evaluated in value stream effects and value propositions, for multiple value streams and lines of business.

4.    Market-based value contributions

In addition to differences in scenario and capability method applications, different value propositions may have different customer satisfaction computations and weights associated with customer preferences such as for different market segments or products.

5.    Product mix impact analysis

Using scenarios, different product mixes can be evaluated and their impact on performance and market value propositions can be compared, analyzed and affected.

VDML for Business Architects: Part 7 of 11, Accountability

Please see the post for VDML for Business Architects: Part 1 of 11, for the introduction to this series of posts.  This part describes how VDML represents the accountability of people and organizations for the management and operation of the business.
1.    Collaboration accountability

Collaborations are the context for all work of the enterprise and interactions with customers and business partners.  Participants in collaborations are accountable for their roles in collaboration activities and organization units in which they are assigned to positions.  Collaborations generally will have a leader/manager role that carries primary responsibility for the overall performance of the collaboration.

2.    Value contribution accountability

Value contributions including cost, timeliness, quality/defects are attributed to capability methods and their activities that are associated with organization units that apply and/or are responsible for the implementation, staffing and improvement of those capability methods.

3.    Accountability to multiple value streams

VDML value streams trace the values of value propositions back to their sources of value.  Conversely, the values of a single activity or capability method can have an impact on multiple value streams.  Both dimensions are important for understanding the impact of changes, particularly for shared capability methods.

4.    Personnel and resource accountability

Organization units are the focus of operational management of the application of capabilities (capability methods).  As such, they have primary responsibility for staffing those capability methods and ensuring availability of the resources required to perform those methods.  Value stream analysis and comparison to actual performance or benchmarks provide a basis for holding specific organization units responsible for their performance.

5.    Policy compliance accountability (proposed VDML extension)

A directory of regulations, policies and requirements must identify the capabilities and activities where compliance must be enforced by the associated organization units.  In some cases this is a matter of monitoring measurements, and in other cases, it involves reporting of oversight/monitoring activities.

6.    Accountability for objectives (proposed VDML extension)

Objectives are elements for monitoring measurements toward a target.  An objective may monitor a single measurement or a complex of measurements, including dependence on completion of other objective(s).  An objective is linked to the responsible organization unit or organizational role.  And the overseeing organization unit or role.  Reporting methods must provide displays of selected sets of objectives of interest to the organization units or roles involved.

7.    Accountability for transformation contribution(s) (proposed VDML extension)

Each phase of a transformation plan identifies the capability methods and/or activities that must be changed, added or deleted.  These are linked to the organization units responsible for the development/acquisition of method/activity design, personnel and acquisition of resources. and implementation.  These provide the basis for setting objectives for the currently pending transformation phase.

8.    Capability performance accountability

Performance of a value chain stage (ref. Michael Porter) is the responsibility of the organization unit responsible for the collaboration or capability method(s) that compose that stage—generally responsibility for the specific stage of a line of business.  The value streams of that stage identify the contributions and thus the performance of capability methods recursively engaged to support that value chain stage.

Many of these capability methods are shared with other lines of business and value streams, and they may not be in the same management chain.  Thus, each capability method is responsible to the users of its services and the operations that consume its deliverables in addition to the organization that manages the capability method operation, resources and the people that perform its roles.  The VDML model represents all these relationships and supports measurement of the dependencies and the impact of changes.

VDML for Business Architects: Part 8 of 11, Value Contribution Analysis

Please see the post for VDML for Business Architects: Part 1 of 11, for the introduction to this series of posts.  This part describes the nature of value streams and their impact on value propositions.  A value stream is the sequences of activities and value contributions that feed a value propositions for particular customers.  A value stream may have many tributaries that converge on a value proposition.  A capability method may participate in multiple value streams.
1.    Value chain stages that aggregate value measurements

Value chain stages (based on Porter’s value chain) are collaborations (capability methods) that delegate to more operationally specific capability methods.  Each value chain stage contributes the aggregated values of the activities and capability methods it engages.  The aggregations extend to delegated capability methods to the extent the model is completed or until contributions of further delegations are estimated or derived from actual operational measurements. This provides meaningful value measurement contributions that are estimated without added cost and time required to develop a more robust model.

2.    Value proposition reflects a customer perspective

A value proposition does not only capture the value measurements associated with the delivery of a product or service, but the measurements are translated to levels of customer satisfaction and weighted according to customer priorities for overall expected satisfaction.  Consequently, it expresses the values that the enterprise expects to deliver to the customer from the customer’s perspective.

3.    Satisfaction level computations

A value proposition component (a line item in a value proposition) provides for the translation of a value measurement to a customer satisfaction level.  This computation will depend on the value type and the target market.

4.    Weighted satisfaction levels

Each value proposition provides for a weight on each value type reflecting the level of interest of customer(s) in the target market.  These provide for computation of a weighted average for an overall value proposition level of customer satisfaction.

5.    Activity-level value contributions

VDML captures value contributions of individual activities to be aggregated up value streams in support of value proposition computations.  The need to assess value contributions at the activity level of activities was recognized by Michael Porter as a limitation of the generally accepted approach to value chain modeling.  Activities can be aligned to actual business operations for capture of actual measurements or development of estimated measurements.

6.    Unit of production value impact

Measurements are based on a unit of production within each capability method.  This enables computation of averages where activity flows converge or diverge.  It also enables the contributions of a capability method engaged by delegations to be appropriately adjusted according to the fraction of units of production contributed by the engaged capability method.  VDML supports these adjustments to the value measurements returned from a delegation.

7.    Value proposition impact analysis

When changes to a capability method affect value measurements, these changes will propagate through all of the value streams in which it participates to update all of the associated value propositions.  A display can trace these value streams to identify the affected value propositions and show the impact.

8.    Multiple market segment value propositions

A value stream may feed different value propositions for different customers or target markets.  Each value proposition then has satisfaction computations and importance weights appropriate to the particular customer or market segment.

9.    Value streams with shared capability methods

Capability methods can be shared across value streams and lines of business for economy of scale and enhanced agility.  Value and performance measurements depend on each context and the scenario.

10. Enterprise-level performance optimization

Capability methods may be engaged by multiple lines of business with different performance measurements, costs and defect rates. Changes to capability methods can be immediately evaluated across all affected value streams and lines of business to measure, balance and optimize adjustments from an enterprise perspective from individual activities to value propositions.

 

VDML for Business Architects: Part 9 of 11, Executive Dashboard Support

Please see the post for VDML for Business Architects: Part 1 of 11, for the introduction to this series of posts.  This part highlights potential application of VDML to define the structure and content of an executive dashboard.  An executive dashboard provides current information about the state and operation of the business. 
1.    Executive dashboard abstraction

VDML provides an abstraction of multiple perspectives on the business suitable for the structure of an executive dashboard.  Operational measurements can be periodically imported for executive monitoring.  This provides operating measurements based on actual operations in the context of a VDML model that is easily understood and explored by executives.

2.    Executive queries

An executive can browse the dashboard based on the VDML model of the business.  For example, an executive might examine the sources of particular value contributions in a value proposition, identify the organizations responsible for those value contributions and examine the effects of these values on other values streams and value propositions.

3.    Ad hoc operating objectives in an executive dashboard

Objectives can be attached to VDML measurements to assess progress as measurements track actual operations in an executive dashboard.

4.    Dashboard exception alerts

Variance measurements in an executive dashboard can be tracked to provide alerts for variations that exceed acceptable tolerances.

VDML for Business Architects: Part 10 of 11, Agile Business Architecture

Please see the post for VDML for Business Architects: Part 1 of 11, for the introduction to this series of posts.  This part describes a recommended business architecture supported by VDML.

1.    Service oriented architecture

VDML is designed to support a service-oriented architecture with services defined by collaborations, particularly capability methods.  However, VDML can also model a silo-oriented architecture and facilitate transformation to a service-oriented architecture by carving out and consolidating capability methods.

2.    Business partner ecosystem

Business network models support analysis of relationships with business partners such as exchange of value propositions and deliverables.  In successful relationships, each participant must realize adequate benefit to sustain the relationships.

3.    Business function outsource modeling

Outsourcing moves business capabilities to services provided by an external business partner.  The VDML business model provides the basis for identification of operations to be transitioned and the points where interactions must occur to engage and oversee the outsourced capabilities.

4.    Meta-methods operate on mainstream operations
 
Certain capabilities operate on the elements of the mainstream business.  For example, maintenance and repair services operate on machines.  Personnel services manage personnel records and benefits.  Financial services manage billing, payments and inventory records and transactions.  Strategic planning activities analyze current circumstances and evaluate potential strategies, transformations or improvements.  Such operations can be modeled in VDML with elements of the mainstream operations represented as business items.

VDML for Business Architects: Part 11 of 11, Business Transformation Extension

Please see the post for VDML for Business Architects: Part 1 of 11, for the introduction to this series of posts.  This part describes the extension of VDML to support business transformation planning and management.

1.    Shared future business design

Failure to achieve and maintain a shared understanding of a business transformation is a major cause of failure to achieve expectations.  VDML supports development of a consistent business design that ensures a clear understanding of intent and requirements across affected organizational units.

2.    Incremental transformation phases (proposed VDML extension)

Incremental transformation phases are represented as VDML model scenarios with the expectation that each scenario represents a viable operating model as an interim step in the transformation.  Transformation work is identified based on the changes from one phase scenario to the next.

3.    Transformation details (proposed VDML extension)

Transformation requirements must be evaluated based on the input/output requirements of the changed capabilities. Changed capabilities must be analyzed to determine the requirements for other source or recipient capability methods.

4.    Transformation progress oversight (proposed VDML extension)

Oversight of transformation progress is supported by key objectives. Of primary interest are objectives to achieve the next phase of the transformation plan.  Objectives identify the responsible manager and persons with an interest in progress on the objective.

5.    Disruption impact/propagation analysis (proposed VDML extension)

Changes required to capability methods, resources and organizations will have impact on related capability methods and organizations linked through deliverable flows and delegations.  These consequential changes must also be identified in the transformation plan for each phase.

6.    Objective dependencies based on flows and transformation phases (proposed VDML extension)

The transformation plan identifies changes by phase, and the associated scenarios determine dependencies and responsibilities affected by those changes.  Consequently, objectives for each phase can be generated for the required changes along with dependencies between objectives based on the requirements for completion of each phase of the transformation plan and dependencies based on deliverable flows within the phase.