Ardoq’s Business Value Stream (BVS) solution enables organizations to document a Business Value Stream, link it to a Value Proposition, and define the Value Stream Stages from which it is formed.

Value Stream Stages are realized by the Business Capabilities or Processes within an organization, which are themselves supported by other architectural components such as applications.

A Business Value Stream (BVS) is a high-level, strategic view of how an organization creates and delivers value to its Stakeholders, including customers, employees, partners, and shareholders. Unlike Lean Value Streams, which focus on the operational view, Business Value Streams emphasize the broader Business Capabilities and strategic activities required to achieve organizational objectives.

Businesses find BVS useful for strategically aligning their operations, capabilities, and resources with their overall goals and delivering customer value. By capturing and analyzing the Value Streams across your organization, you can realize multiple benefits resulting from a clear understanding of the value contributed by each Business Capability and Process, and how they connect to the rest of the enterprise architecture.

This metamodel article discusses the component types, reference types, and fields used by the Business Value Stream solution.

To learn more and to better understand the foundation for the method, please refer to the Business Value Stream Purpose, Scope, and Rationale.

Content

At its core, the Business Value Stream solution focuses on:

One or more Value Streams deliver the Value Proposition. We use the Value Proposition component type, which is referenced from the Value Stream component, with reference “Delivers”. The Value Proposition component type contains the high-level value proposition, which is captured in the description field.

The Value Stream component type is a structured representation of how an organization delivers value to its Stakeholders through a sequence of high-level Stages. It provides a business-wide view of how value is created, enabling alignment between strategy, operations, and technology.

Start by creating a high-level Value Stream, a single component that delivers the Value Proposition for the whole company. If, at a later date, more detailed Value Streams are required, then these can easily be added.

The Value field captures the value created by the Value Stream. This gives a high-level context for the Value Stream stage and the overall value it delivers. For example, the Value Stream “Market awareness and customer engagement” may deliver a value proposition of “prospects learn about a platform that can solve their challenges around enterprise architecture, change management, and strategic alignment.” It is quite easy to forget this when we start the analysis of Business Capabilities and Processes.

The Vale Stream Stage component type represents a key step within a Value Stream, indicating a significant phase in delivering value to Stakeholders. Each stage reflects a transformation or critical business activity that contributes to the final outcome. Each stage can also reference the Process or Business Capability that realizes it with a reference “Is Realized By”.

Business Capabilities and/or Processes are enabling the delivery of value in each stage. Both can be used and are referenced with the reference type “Is Realized By”.

Business Capabilities can themselves be delivered through Processes, in which case the “Is Realized By” reference type can refer to the Business Processes from the Business Capability (instead of the Value Stream Stage).

The Process component represents a series of interconnected activities or tasks. For a detailed description, refer to Business Process Management.

If you have implemented the Business Process Management solution, you will have a Business Process Workspace populated with your Business Processes.

To access more information about Business Process Management, refer to the document Business Process Management Metamodel.

Business Capabilities are the essential functions a business performs. It is the Business Capabilities that realize the value. These are captured in the Business Capability Workspace, and when you have implemented our Business Capability Modeling solution, you will have a Business Capability Workspace populated with your Business Capabilities.

To access more information about Business Capabilities, refer to the document Business Capability Modeling and Realization Metamodel.

We use the Person component from the People workspace to identify the Owner of the Value Stream.

For more information about modeling people, refer to the document Modeling people roles and relationships in Ardoq.

A Person component owns the Value Stream and is referenced from the Person component to the Value Stream component with reference type “Owns”.

To help identify the Value Stream Owner (VSO) and the type of role and person, refer to the document Purpose, Scope, and Rationale document for Business Value Streams.

A Role represents the set of skills, competencies, behaviors, or responsibilities a person or organization needs to demonstrate while fulfilling their duties. Crucially, like any logical component, a Role specifies the characteristics of a position without specifying how they are realized, or in this case, who fulfills them.

Role modeling enables architects and analysts to allocate activities, responsibilities, or behaviours at design time, to what people are required to do, or to analyze issues with current activities, responsibilities, or behaviours.

If you need more information about how to model roles, please refer to the document Modeling People, Roles, and Relationships in Ardoq.

Each Value Stream has Stakeholders who receive value from the Value Stream. These are represented by component type Role and Organizational Unit and are connected to the Value Stream component with reference type “Is Stakeholder In”.

For Stakeholder Management, it is useful to identify the Stakeholders for each Value Stream Stage and the Power and Interest they have. These Stakeholders can be an organizational unit, for example, Marketing may be a Stakeholder in the Market Awareness and Customer Engagement Value Stream stage. They can also be external entities such as suppliers, prospective customers, customers, shareholders, or any other organization. Stakeholders can also be roles. For example, the Customer Success Manager is a Stakeholder in customer onboarding. For more information, refer to the document Purpose, Scope, and Rationale for Business Value Streams.

The decision on which Stakeholders you identify is yours, but we suggest you identify ownership of the Value Stream stage together with identified Stakeholders. Where a whole organization is a Stakeholder, such as Marketing, you can create that reference. However, individual roles are usually more useful when heatmaps are applied.

The same is true of Value Streams. If the company only has one Value Stream, then everyone inside the company is a Stakeholder. It is therefore preferable that individual Value Streams or Stages that deliver the value have Stakeholders, not the high-level ones. If you have several Value Streams, apply the “Is Stakeholder In” reference at that level.

Using both Role and Organization can give you another level of abstraction to see who within each organization is the Stakeholder.

This reference type contains a field (Triggers) that allows the user to identify which Stakeholder is the trigger for that Value Stream and each Value Stream Stage, if required.

This field is a check box on the reference, which is set when creating the reference or updated by selecting the appropriate reference and editing its properties.

If selected, two fields appear on the reference, “Power” and “Interest”, both of which are number fields (1-5). These are used for Stakeholder management.

The fields on the “Is Stakeholder In” reference are very useful for Stakeholder management. For more information, refer to the document How to Record and Map Stakeholders with Ardoq.

Organization is the top-level node representing the main organization or External Organizations. Where relevant, each Organization should be modeled in a separate workspace, as this focuses the workspace on the relevant organization.

It also allows any potential communications or data collection through broadcasts and surveys to be focused on the relevant Organization. While this creates additional overhead for workspace management, it allows architects to work within Ardoq to focus the collaboration of each Organization to a particular workspace.

For more information on mapping your Organization, refer to the document Organizational Modeling.

The references and reference fields for Organizations are identical to those for roles. The “Is Stakeholder In” reference type enables a clear Stakeholder view of Value Streams and Value Stream Stages.

The fields in the “Is Stakeholder In” reference are useful for Stakeholder Management. These are described in the document How to Record and Map Stakeholders with Ardoq.