6. Plan Functions
Description
The Plan functions (formally part of Strategy to Portfolio) provide organizations with a framework for interconnecting the different groups involved in managing a portfolio of Digital Products for the business. It ensures Policy compliance, tracking of Scope Agreements, Portfolio Backlog, and preparation for the Build functions. The end-to-end portfolio view provided by the Plan function objects often overlooked during portfolio planning activities.
The Plan functions enable the traceability of Digital Product demand from Strategy to Enterprise Architecture and into the Product Portfolio as investment opportunities that deliver value for the business.
The Plan functions contain the following functional components:
-
Strategy:
-
Policy component
-
Strategy component
-
Enterprise Architecture component
-
-
Portfolio:
-
Portfolio Backlog component
-
Proposal component
-
Product Portfolio component
-
The Plan functions provide a method for driving change through the Proposal functional component for new or improved Digital Products and services from the business in the form of Scope Agreements. Change requests and consumer demands materialize as: Strategic Objectives, new Policies, updated or reprioritized Architecture Roadmap Items, Portfolio Backlog Items, or new value streams. These inputs are then used to generate Scope Agreements within the Proposal functional component.
Related Value Streams
The following value streams use one or more functional components from the Plan functions:
-
Evaluate
-
Explore
Business Benefits
The Plan functions describe a prescriptive framework of required functional components and data objects so organizations can better control Strategy alignment to the Investment and Product Portfolio functional components.
The key benefits of using the Plan functions are:
-
Holistic portfolio view across the Strategy, Enterprise Architecture, Portfolio Backlog, Proposal, and Product Portfolio functional components
-
Portfolio decisions based on business priorities
-
Product/service lifecycle tracking through conceptual, logical, and physical domains
-
Re-balance investments between strategic and operational demand
-
Prioritized investment based on all portfolio facets including cost/value analysis, impacts on architecture, product/service roadmap, business priorities, and feasibility
-
Solid communication with business stakeholders through Scope Agreements and roadmaps
The Plan functions enable organizations by providing the framework for interconnecting the different functions supporting Portfolio Management; including Strategy, Enterprise Architecture, Portfolio Backlog, Proposal, Product Portfolio, and Digital Product. Used together, these functional components can provide data consistency and proper data object hand-offs to help optimize the organization’s Product Portfolio function. The implementation plan is formulated and tracked as assumptions are validated and investments are re-balanced between strategic and operational demand.
6.1. Strategy Function
The Strategy Function is centered around managing and evolving the digital strategy.
6.1.1. Policy Functional Component
Purpose
The Policy functional component manages the creation, review, approval, and audit of Policies.
The Policy functional component supports the value streams:
Functional Criteria
The Policy functional component:
-
Shall align and map to Enterprise Architecture
-
Shall enable the review and approval of Policies based on roles and responsibilities
-
Shall provide visibility into Policy attributes such as types, status, non-compliance, audit history, risks, and issues
-
Shall manage the governance of Policies associated with downstream value stream stages of the product and service lifecycle
-
Shall manage both internal and external Policies (e.g., security, pricing/costing, resources, regulatory, risk, information) and history of revisions
-
Shall track Policy exceptions and waivers with consistent identification, evaluation, and status reports for managing corrective actions
6.1.1.1. Policy Data Object
Purpose
The Policy data object defines and maintains a Policy to the digital organization.
Key Attributes
The Policy data object shall have the following key data attributes:
-
Id: unique identifier of the Policy
-
Name: name of the Policy
-
Description: description/details of the Policy
-
Applicable Geography: to which geographies the Policy applies; e.g., certain policies could be country-specific or may have country-specific customizations
Key Data Object Relationships
The Policy data object shall maintain the following relationships:
-
Policy to Digital Product (n:m): multiple Policies might be applicable for a single product or service, or a single Policy may be applicable for multiple products or services
-
Policy to Architecture Roadmap Item (n:m): multiple Policies might be applicable to the Architecture Roadmap
-
Policy to Portfolio Backlog Item (n:m): multiple Portfolio Backlog Items may be sourced from Policies or may reference Policies to demonstrate compliance
-
Policy to Requirement (n:m): multiple Requirements may be sourced from Policies or may reference Policies to demonstrate compliance
6.1.2. Strategy Functional Component
Purpose
The Strategy functional component manages the creation and maintenance of the portfolio strategy in alignment with the overall business/enterprise strategy.
The Strategy functional component supports the value streams:
Functional Criteria
The Strategy functional component:
-
Must align to business objectives and goals
-
Shall enable periodic review of the portfolio Strategic Themes
-
Shall manage the creation and closure of Strategic Objectives as required to address Strategic Themes
-
Shall provide visibility of both Strategic Themes and initiatives to as broad an audience as possible
-
Shall ensure traceability of the strategic initiative to the impacted value streams
-
Must maintain alignment with the Architecture Roadmap(s)
6.1.2.1. Strategic Theme Data Object
Purpose
The Strategic Theme data object is a statement of direction and priorities that summarize Strategic Objectives to provide business context for portfolio decision-making.
Key Attributes
The Strategic Theme data object shall have the following key data attributes:
-
Id: unique identifier; e.g., number of the Strategic Theme
-
Name: descriptive name of the Strategic Theme
-
Description: description/details of the Strategic Theme
Key Data Object Relationships
-
Strategic Theme to Strategic Objective (n:m): a Strategic Theme may contribute to the creation of many strategic initiatives; a strategic initiative could be created to address objectives associated to more than one Strategic Theme
6.1.2.2. Strategic Objective Data Object
Purpose
The Strategic Objective data object defines specific actionable goals and measurable outcomes for identified stakeholders and should be related to/or provide key results for the business case.
Key Attributes
The Strategic Objective data object shall have the following key data attributes:
-
Id: unique identifier; e.g., number of the Strategic Objective
-
Name: descriptive name of the Strategic Objective
-
Description: description/details of the Strategic Objective
Key Data Object Relationships
-
Strategic Objective to Strategic Theme (n:m): a Strategic Objective defines details of Strategic Themes; in some instances a given objective will deliver on several themes
-
Strategic Objective to Portfolio Backlog Item (n:m): a Portfolio Backlog Item can be part of delivering a Strategic Objective and thus this relation can indicate the importance of a Portfolio Backlog Item as well as indicating how an objective is to be delivered
-
Strategic Objectives to Architecture Roadmap Item (n:m): define what activities will deliver a given objective
6.1.3. Enterprise Architecture Functional Component
Purpose
The Enterprise Architecture functional component manages the development of Enterprise Architectures that will ensure a coherent and optimized portfolio of Digital Products that address enterprise business needs on a long-term basis.
The Enterprise Architecture functional component supports the value streams:
Functional Criteria
The Enterprise Architecture functional component:
-
Shall be the system of record (authoritative source) for all Architecture Roadmaps and Architecture Roadmap Items
-
Shall develop an Architecture Vision, based on business strategy, goals, and high-level Portfolio Backlog Items that define the capabilities and business value to be delivered
-
Shall develop or use existing baseline state Business, Information, Application, Technology, and Security architectural artifacts based on stakeholder assessments of the current state
-
Shall develop target state Business, Information, Application, Technology, and Security architectural artifacts based on strategies, principles, and policies
-
Shall identify gaps between Baseline and Target Architectures
-
Shall create an architecture definition document (or Architecture Blueprint)
-
Shall identify the migration strategy
-
May identify intermediate Architecture Roadmap Items that will deliver continuous business value, if an incremental approach is required
-
Shall identify re-usable building blocks, which are a package of functionality designed to meet business needs across the organization
The building blocks can either be Architecture Building Blocks (ABBs) or Solution Building Blocks (SBBs), where ABBs are realized through the application of the ADM and guide the creation of SBBs; see the TOGAF Standard.
-
Shall identify Digital Products (SBB) that realize the Target Architecture
-
Shall ensure that the architectural artifacts are compliant with all standards and policies, including security standards and policies
-
Shall ensure that the realized architecture meets the KPIs and SLAs
-
Shall ensure that each Architecture Blueprint addresses Portfolio Backlog Items and stakeholder concerns
-
Shall ensure that the output of the Enterprise Architecture functional component is used by the Product Portfolio functional component to define the Digital Products that need to be created
-
Shall ensure the compliance of created Digital Products to the Architecture Roadmap and Architecture Blueprint artifacts
-
Can receive Strategic Objective information which includes the objectives and some content based upon which the Enterprise Architecture is developed if a Strategy functional component exists
-
Can receive Portfolio Backlog Item information from the Portfolio Backlog functional component used to create the Architecture Roadmap and Architecture Blueprint if a Portfolio Backlog functional component exists
6.1.3.1. Architecture Roadmap Item Data Object
Purpose
The Architecture Roadmap Item data object is produced in the context of architecture work and lists individual work packages in a timeline that will realize the Target Architecture.
-
The Architecture Roadmap Item data object is a planning item that refers to a cohesive set of architectural artifacts
-
The Architecture Roadmap Item defines a stable step towards the Target Architecture that will achieve the business goals and respond to the strategic drivers
Key Attributes
The Architecture Roadmap Item data object shall have the following key data attributes:
-
Id: unique identifier of the Architecture Roadmap Item
-
Name: name of the Architecture Roadmap Item
-
Status: lifecycle status of the Architecture Roadmap Item
-
TargetDate: planned date of the realized architecture of this specific Architecture Roadmap Item
-
Roadmaps: name of the roadmap(s) that will contain one or several Architecture Roadmap Items
-
Description: description of the Architecture Roadmap Item
Key Data Object Relationships
The Architecture Roadmap Item data object shall maintain the following relationships:
-
Architecture Roadmap Item to Product Backlog Item (n:m): establish what major program increments will implement the Architecture Roadmap Item
-
Architecture Roadmap Item to Value Stream (n:m): establish which value stream will be created or improved by implementing the Architecture Roadmap Item
-
Architecture Roadmap Item to Architecture Blue Print (n:m): establish which blueprint will be supported by the work in the Architecture Roadmap Item
-
Architecture Roadmap Item to Strategic Objectives (n:m): establish the strategic rational for a given Architecture Roadmap Item
-
Architecture Roadmap Item to Policy (n:m): multiple Policies might be applicable to the Architecture Roadmap
6.1.3.2. Architecture Blueprint Data Object
Purpose
The Architecture Blueprint data object represents the development of the Enterprise Architecture which details the building blocks (including Digital Products) and how these relate to each other. It contains a list of architecture views or architectural artifacts that depict a stable and approved state of the architecture.
Key Attributes
The Architecture Blueprint data object shall have the following key data attributes:
-
Id: unique identifier of the Architecture Blueprint
-
Name: meaningful name of the Architecture Blueprint
-
Description: short description of the purpose of the Architecture Blueprint
-
Version: version of the Architecture Blueprint
-
Artifact List: list of architectural artifacts that describe Business, Data, Application, and Technology aspects of the Architecture Blueprint
Key Data Object Relationships
The Architecture Roadmap Item data object shall maintain the following relationships:
-
Architecture Roadmap Item to Architecture Blueprint (n:m): one Architecture Roadmap Item may be described by one or several Architecture Blueprints
-
Architecture Blueprint to Digital Product (n:m): traceability is maintained between one or more Architecture Blueprints and Digital Products
6.1.3.3. Value Stream Data Object
Purpose
The Value Stream data object represents an end-to-end view of how value is achieved for a given stakeholder. A Value Stream is depicted as an end-to-end collection of value-adding activities that creates a result for a customer, stakeholder, or end-user. Each stage of a Value Stream has an entrance criteria, exit criteria, and a value item. The Value Streams of an enterprise may be structured as a Value Stream map. There are two types of Value Streams in the enterprise: Value Streams for running the business and Value Streams for optimizing the business with Digital Products. Examples of business Value Streams include: Onboard Employee, Acquire Material, Manufacture Product, and Acquire Insurance Product. There are seven Value Streams identified in the IT4IT 3.0 Standard for managing the Digital Product lifecycle:
-
Evaluate: for managing the Product Portfolio
-
Explore: for managing the Digital Product
-
Integrate: for delivering Product Releases
-
Deploy: for managing the transition of a Product Release to production
-
Release: for controlling the Service Offers
-
Consume: for managing subscriptions to services
-
Operate: for ensuring an Actual Product Instance is delivered according to contract
Key Attributes
The Value Stream data object shall have the following key data attributes:
-
Id: unique identifier of the Value Stream
-
Name: name of the Value Stream
-
Description: description of the Value Stream
-
Stakeholder: name of the Stakeholder that triggers and gets value from the Value Stream
-
Value Stream Id (N): unique identifiers of the related Value Streams
Key Data Object Relationships
The Value Stream data object shall maintain the following relationships:
-
Value Stream to Architecture Roadmap Item (n:m): establish which Value Stream will be created or improved by implementing the Architecture Roadmap Item
-
Value Stream to Digital Product (n:m): define which Digital Products contribute to delivering the value specified in the Value Stream
6.2. Portfolio Function
The Portfolio function is centered around managing the portfolio of Digital Products.
6.2.1. Portfolio Backlog Functional Component
Purpose
The Portfolio Backlog functional component provides for the lifecycle management and visibility of the Portfolio Backlog Items as grouped into collections of work and prioritized.
The Portfolio Backlog functional component supports the value streams:
Functional Criteria
The Portfolio Backlog functional component:
-
Shall provide for the transparency of proposed, accepted, rejected, and prioritized Portfolio Backlog Items
-
Shall execute the processes necessary for reviewing, accepting, creating, prioritizing, updating, and closing Portfolio Backlog Items
6.2.1.1. Portfolio Backlog Item Data Object
Purpose
The Portfolio Backlog Item data object is a discrete and specific statement of work with acceptance criteria, funding requirements, and detailed work definitions. It may be a collection of many smaller work items, such as work packages or Product Backlog Items.
Key Attributes
The Portfolio Backlog Item data object shall have the following key data attributes:
-
Id: unique identifier; e.g., number of the Portfolio Backlog Item
-
Name: descriptive title of what the Portfolio Backlog Item represents
-
Description: short description of the work contained within the Portfolio Backlog Item
-
Prioritization: current priority on the Portfolio Backlog
-
Acceptance Criteria: what must be accomplished by the work in order to consider the item complete and accepted
-
Related Products: products that are impacted by the execution and completion of this work
-
Demand Profile: detailed list of how this Portfolio Backlog Item will consume resources such as labor, contracts, infrastructure, etc.
-
Cost Estimation: estimated cost derived from the demand profile
Key Data Object Relationships
The Portfolio Backlog Item data object shall maintain the following relationships:
-
Portfolio Backlog Item to Strategic Objective (n:m): a strategic initiative may drive the creation and prioritization of many Portfolio Backlog Items; the Portfolio Backlog Item may satisfy the objectives of many strategic initiatives
-
Portfolio Backlog Item to Architecture Roadmap Item (n:1): a Portfolio Backlog Item must align to the authoritative Architecture Roadmap Item
-
Portfolio Backlog Item to Policy (n:m): Portfolio Backlog Items may be sourced from Policies or may reference Policies to demonstrate compliance
-
Portfolio Backlog Item to Scope Agreement (1:1): a Portfolio Backlog Item can have one corresponding Scope Agreement
-
Portfolio Backlog Item to Digital Product (n:m): a Portfolio Backlog Item may be executed or impact many Digital Products; a Digital Product may be executing work against many Portfolio Backlog Items
-
Portfolio Backlog Item to Product Backlog Item (1:m): Portfolio Backlog Items may contain many Product Backlog Items; a Product Backlog Item is related to one Portfolio Backlog Item
-
Requirement to Portfolio Backlog Item (n:m): Requirements can be associated with one or more Portfolio Backlog Items
6.2.2. Proposal Functional Component
Purpose
The Proposal functional component evaluates the feasibility and resources necessary to respond to a specific demand and manages the portfolio of proposals in their various states: proposed, approved, active, deferred, or rejected. The Scope Agreement is the authoritative source for the list of all proposals requested over a given time period. It represents the agreement between the demanding party (usually the business) and the delivery party as to the services to be provided.
For as much as the scope may be sketched out already in the Portfolio Backlog Items, the scope defined in the Proposal functional component undergoes a delivery estimation effort. Therefore, a proposal represents estimated and rationalized demand. In doing so, other objects and functional components of the IT4IT Reference Architecture should support the proposal definition task. The Enterprise Architecture, Digital Product, and Investment functional components will likely be solicited and their data relationships made consistent to develop solid proposals.
The Proposal functional component supports the value streams:
Functional Criteria
The Proposal functional component:
-
Shall create a Scope Agreement from rationalized Portfolio Backlog Items in the data object repository
A Scope Agreement:
-
May follow an expedited analysis and approval for high-priority urgent items or Agile development proposals
-
May follow a structured analysis and approval; for instance, via annual planning activities
A Scope Agreement following an expedited analysis and approval:
-
Shall create a proposal from a rationalized Portfolio Backlog Item where the item requires high urgency due to business impact on an existing service/Digital Product
-
Shall allow a quick evaluation of the proposal and a decision on its approval; and if rejected, will then notify the Portfolio Backlog functional component
-
Shall create an updated Scope Agreement and update the corresponding in-flight Product Backlog Item data object for all activities associated with a newly approved demand
Scope Agreements following a structured analysis and approval:
-
Shall create proposals from rationalized Portfolio Backlog Items in the Portfolio Backlog Item data object repository
Rationalized items are grouped based on priority and themes for a proposal creation purpose. Not all rationalized items will be grouped within proposals as a priority and a cut-off must be decided.
-
May periodically produce proposals throughout the year or once per planning period
-
Shall create a high-level labor consumption model for a proposal (for example, one project manager, five developers, and two quality assurers for the proposal) based on labor estimates
If a Resource Management Offer exists in the Offer catalog, then the Proposal functional component shall receive the resource price from the mentioned Offer and validate the labor consumption model against available internal and external labor pools.
-
Shall create a high-level asset (non-labor) consumption model for a proposal based on asset estimates
If an Asset Management Offer exists, then the Proposal functional component shall receive the asset price from the mentioned Offer.
-
Should validate the asset consumption model against available internal and external assets; for example, traditional/private cloud/managed cloud/public cloud
-
Should model the ongoing labor and non-labor budget for annual and future operations
-
May define tangible and intangible benefits for each proposal
Tangible benefits may be cost savings or revenue growth, whereas intangible benefits may be strategic initiative support, competitive advantage, or compliance achieved. Work with a finance organization to validate tangible benefits can involve utilizing industry-specific methods of measuring the value of business processes and estimating the impact of the proposal on performance metrics. These planned benefits will characterize the anticipated business value.
-
Shall ensure the proposal meets the technology policies
-
Should rank proposals based on benefits and risks, labor and non-labor consumption models, ROI, or other defined evaluation criteria
-
May build proposal portfolio scenarios using proposals, conduct “what if” analysis on the proposal scenarios, and approve the optimal proposal scenario and its proposals
-
Shall send proposed investments to the Investment functional component for scoping and investment decisions
-
Shall update Scope Agreement(s) to compare approved baseline and actual resulting benefits derived from completing the Digital Product delivery, thus comparing planned with actual delivery
In addition, the Proposal functional component:
-
Shall review the Scope Agreement change request from the Integrate value stream
The Digital Product team working to deliver the approved Scope Agreement may ask for change requests related to budget, resource, timeline, or scope, and may evaluate the change request and take action to update the existing Scope Agreement.
-
Shall consider the Product Portfolio as the authoritative source for the list of deliverables or services that will be rendered during a product lifecycle
-
May create Product Portfolio views for specific organizations such as a line of business portfolio or functions like financial views; the Product Portfolio is used for rationalizing and tracking resources across Product teams to best deliver on all products
-
Should actuate the Product Portfolio entries through a Project Management system
The Product Portfolio functional component shall report back to the Investment functional component in order to accurately track progress and outcomes for a given Scope Agreement.
-
Shall identify the security controls necessary for protecting the various classifications of data
6.2.2.1. Scope Agreement Data Object
Purpose
The Scope Agreement data object represents a proposal and is created from rationalized Portfolio Backlog Items. Scope Agreements reflect budget, cost/benefit projections, scope, status, and other key attributes of proposed work. Views can be created for specific functions, company-wide or for a line of business; for example, for building the investment plan of record for the company or for a specific line of business or function. The Scope Agreement can be written in the context of portfolio or product level concerns.
Key Attributes
The Scope Agreement data object shall have the following key data attributes:
-
Id: unique identifier of the Scope Agreement
-
Description: details of the Scope Agreement
-
Business Entity: business or geographic unit
-
Anticipated Business Value (optional): projected business value, over a given time period, anticipated once the corresponding products and capability have been delivered
-
Proposed Budget: requested budget of the Scope Agreement; this should be broken down into a build and a run budget
-
Approved Budget: approved budget of the Scope Agreement; this should be broken down into a build and a run budget
-
Status: Scope Agreement (e.g., created, proposed, approved, rejected, deferred)
-
Context: portfolio level, product level
Key Data Relationships
The Scope Agreement data object shall maintain the following relationships:
-
Scope Agreement to Portfolio Backlog Item (n:m): one Scope Agreement can be associated to one or more demand data objects
-
Scope Agreement to Budget Item (n:1): this relationship helps track the budget allocated to each Scope Agreement
-
Scope Agreement to Product Backlog Item (1:n): this relationship helps track Digital Product(s) to each Scope Agreement
6.2.3. Product Portfolio Functional Component
Purpose
The Product Portfolio functional component structures and organizes all of the different types of Digital Products managed by the organization. Digital Products are grouped into portfolios that allow for the grouping of like Digital Products based on ownership, value stream alignment, product lines, strategic investment groups, and prioritization.
Each Digital Product is managed based on common criteria and attributes that provide the data to properly manage them throughout their lifecycle. Managing dependencies and dependents of the Digital Products is a critical aspect of the Digital Product, as well as making portfolio decisions.
While the Product Portfolios may be arranged in any way an organization requires, there are three basic top portfolio tiers to facilitate strategic planning:
-
Market-facing – Digital Product offerings used by customers, organized by product lines, versions, or models accessed by a human or machine interface
-
Internal-facing – Digital Product offerings used by employees, manufacturing, and other automaton tasks
-
Foundational – common and foundational Digital Products often used to build or facilitate other Digital Products such as infrastructure, networking, platform, and other commodity building blocks
These three portfolios allow for relevant strategic discussion and funding decisions to be made more readily, without needing to identify every specific Digital Product affected.
The Product Portfolio functional component supports the value streams:
Functional Criteria
The Product Portfolio functional component:
-
Must include all Digital Products managed by the organization
-
May support a taxonomy of portfolios with sub-portfolios, and ultimately contained Digital Products
-
Must provide, via specific Product Designs and Product Releases, Service Offers describing the contract, rules, warranty, and other consumer-based attributes used to establish a contract
-
Must track consumer contracts, which may be simple promises, acceptance of usage terms, Subscriptions, or binding legal agreements
-
Shall support strategic funding and de-funding activities at a portfolio level, and infer decisions on all contained Digital Products
-
Shall review input from organizational strategy, consumers, and market sources to propose portfolio changes that decide whether to keep, retire, increase, or decrease investment
-
Shall track all backlog items used for prioritizing investment and potential changes
-
Shall assess effectiveness, efficiency, and satisfaction of the Service Offers being consumed
-
Should aggregate all metrics from dedicated resources, dependencies, and consumption to include total costs, performance, consumption, capacity, resources, risks, benefits, quality, fitness-for-purpose, etc.
-
Shall manage an inventory of underlying shared resources, systems, Service Offers, and instances
-
Shall track all consumers such as users, instances, and machine/API dependencies
-
Shall compare Digital Products with similar ones to identify rationalization opportunities
-
Shall create, review, and update Digital Products
-
Shall create and maintain service blueprints and end points
-
May share roadmaps with market, consumers, peers, partners, and dependent Digital Product Managers
-
May have roadmaps that include major and minor versions/models
-
Should ensure compliance with all applicable Policies if a related Policy exists
-
Shall aggregate charges from the Chargeback functional component if a Chargeback functional component exists
-
May send the operation charge acceptance to the Chargeback functional component if a Chargeback functional component exists
6.2.3.1. Digital Product Data Object
Purpose
A Digital Product data object is an entity representing the Digital Product throughout its entire lifecycle. It is used to organize activities across all value streams.
A more elaborate description of Digital Product is provided in the Digital Product chapter, to include types of Digital Products, examples, and rationale for definitions as supported by this data object.
Key Attributes
-
Id: unique product identifier
-
Name: descriptive, common name of the Digital Product
-
Description: short description of the Digital Product
-
Product Manager: name of the Digital Product Manager
-
Investment Status: status of the Digital Product; e.g., invest, divest, sustain, retired, etc.
-
Portfolio: portfolio to which the Digital Product belongs
-
Business Criticality: indication of the importance of the Digital Product for the business
-
Security Risk: indication of the business risk if the Digital Product is compromised
-
Budget: approved budget for ongoing resources, development, maintenance, and services
-
Total Cost of Ownership (TCO): the total cost of ownership of the Digital Product (includes all development, run, enhancement, and overhead charges for systems and shared costs)
-
Profit/Loss: calculated chargeback/showback against TCO for the Digital Product
Key Data Object Relationships
The Digital Product data object shall maintain the following relationships:
-
Digital Product to Policy (n:m): multiple Policies might be applicable for a single Digital Product or a single Policy may be applicable for multiple Digital Products
-
Digital Product to Value Stream (n:m): traceability is maintained between Digital Products and the Value Stream it supports
-
Digital Product to Portfolio Backlog Item (1:n): one Digital Product may be related to one or more Portfolio Backlog Items
-
Digital Product to Architecture Blueprint (n:m): traceability may be maintained between one or more Digital Products and the Architecture Blueprint drawings, diagrams, and other planning documents
-
Digital Product to Scope Agreement (n:m): Digital Products may have one or more Scope Agreements associated with them
-
Digital Product to Product Design (1:n): Digital Products will have one or more Product Designs associated with each version/model of the Digital Product
-
Digital Product to Digital Product (n:m): a Product can depend on services being delivered by other Products