The Open Group IT4IT™ Standard

A Value Network is a construct that defines the relationships across the value-creating functions that deliver value.

Within the IT4IT framework it is used to describe the model of the digital business function. It includes primary activities such as planning, production, consumption, fulfillment, and support. It also includes supporting activities such as Finance, HR, Governance, and Supplier Management.

The Value Network concept breaks with the waterfall-oriented aspect of the original Value Chain construct and makes each value-creating activity both consuming and value-producing to potentially many other activities.

A value stream describes the key value-creating activities for discrete areas within the Value Network where some unit of net value is created or added to the Digital Product as it progresses through its lifecycle. The IT4IT Reference Architecture defines seven essential value streams for digital management. These are referred to as the IT4IT Value Streams; see Figure 5.

Notation and Naming

The IT4IT Standard has both a simplified notation and a notation aligned with the ArchiMate language, as pictured in Figure 77.

As a general rule, the IT4IT Value Streams are named using:

Note that occasionally the verb can be used in connection with the essential (backbone) data object that the value stream works on. This is only in the description, and not the normative name. Also note that this document breaks with the tradition of using a x2y notation like “Detect to Correct”. This brings it more in line with how similar value streams are named in some Agile frameworks. Finally note that the value streams are not prepended with the word “continuous”, which is often found in Agile text books. The prepending of "continuous" is considered a maturity construct and should not be part of the name.

The IT4IT Reference Architecture uses the ArchiMate grouping construct as a way of grouping the functional components and data objects together to provide context for the functionality that organizations must deliver.

This can be used as a basis for capability planning in an organization but the standard does not prescribe what capabilities a Digital Organizations should build.

The normative IT4IT Standard defines a grouping at two levels:

At Level 1, the IT4IT Standard defines the following functional groups:

As well as the Support functions that are referenced but are not normative definitions in the IT4IT Standard.

Each one of these is then further decomposed at Level 2 to provide more structure to the reference architecture.

Note that the groupings are simply a way of grouping related functional components together to be able to talk about functionality in a more abstract way, such as Support functions, Assure functions, or simply Run functions. When the IT4IT Reference Architecture is used to implement digital management in a real organization it is necessary to also do capability mapping, as it remains an important activity for organizations. Detailed capabilities that would include process and people aspects are not included as part of the normative documentation. Instead, other documents (guidance documents) will provide this level of detail. The objective of the IT4IT Reference Architecture is to convey, in a prescriptive fashion, the key data objects, relationships, and components that are foundational for all IT organizations. Figure 78 gives an example of a possible decomposition of the IT4IT normative Level 1 and Level 2 groups into detailed capabilities.

There is also Supporting Functionality within the Value Network model, such as Supplier & Vendor Management, Workforce Management, and Financial Management. As with detailed capabilities, these do not define the Supporting Functions in details, but do define some of the essential data objects and functional components that are expected from the Supporting Functions in order for the primary functionality and value streams to work.

Notation and Naming

The IT4IT Standard uses the ArchiMate grouping types and a containment notation to indicate decomposition and to illustrate which functional components support a given functional group.

As a general rule, the IT4IT Functional Groups are named using:

A functional component is the smallest unit of technology that can stand on its own and be useful as a whole to a Digital Practitioner (or IT organization). It must have defined input(s) and output(s) that are data objects and must have an impact on a key data object that it controls. Typically, a functional component controls and/or manages a single key data object, but this is not dictated by the architecture; it can control several, especially if they are intrinsically connected.

Examples of functional components include Event, Product Backlog, Defect, etc. The IT4IT Reference Architecture contains only those functional components that have an impact on key data objects. There will be other technology components and management systems used by IT organizations in the normal course of business, but that are not considered part of the prescriptive IT4IT Reference Architecture. Examples of these types of components could include Corporate Finance systems, HR applications, and Contract Management systems. These will be supplied by the Supporting Capabilities. These are not normative but in some cases the reference architecture will make reference to those.

Notation and Naming

The IT4IT Reference Architecture uses both a simplified and an ArchiMate notation style. At Level 1, the informal notation renders primary functional components as blue rectangles (see Figure 80). Secondary functional components are rendered as gray rectangles. Functional components are represented formally in the ArchiMate language using the “Application Function” type.

As a general rule, the IT4IT Functional Components are named using:

Occasionally the name is appended with the word “component” as a shorthand for “functional component”.

A Key Data Object represents data (records, information, and so on) that annotate or model an aspect of a Digital Product being planned, developed, offered, or consumed. Data objects can take a digital or physical form and can be comprised of structured, semi-structured, or unstructured data. Our definition of Key Data Object is aligned contextually with the Object Management Group^® (OMG^®) definition of artifact. In UML, the OMG defines artifact as:

“… the specification of a physical piece of information that is used or produced by a software development process, or by deployment and operation of a system. Examples of artifacts include model files, source files, scripts, and binary executable files, a table in a database system, a development deliverable, or a word processing document, a mail message.” [UML]

Examples of data objects include incident records, training videos, requirements documents, etc. These types of data objects contribute in some way to define and control a Digital Product over the course of its lifecycle. There are also “special” data objects that represent an abstraction or view of a specific product; for example, a system diagram, release package, or a binary executable file; this provides a “view” of a product to various personas at different stages of the product lifecycle. These special data objects and their relationships form a “backbone” that binds together all of the information needed to offer and manage a Digital Product, thus they are referred to as Digital Product Backbone data objects.

The central focus of the IT4IT Forum has been to identify the data objects that play a “key” role in the product lifecycle. In other words, the reference architecture focuses exclusively on the data objects that are mandatory for ensuring end-to-end traceability of the product lifecycle operationally and/or financially. There are other data objects used across the digital landscape to facilitate various needs or activities (e.g., company-specific processes), but these are considered to be secondary or auxiliary and outside the prescriptive control of the IT4IT Reference Architecture.

Notation and Naming

The IT4IT Reference Architecture utilizes both a simplified and an ArchiMate notation for data objects so that the work can be easily understood by both architects and non-architects. In the Level 1 model, a simplified notation that depicts data objects as circles is used. Color is used to specify whether a data object is key data object (black) or a backbone data object (orange). Data objects are modeled formally in the ArchiMate language using the “Data Object” type, as shown in Figure 81.

Text is also important in communicating the concepts represented in the model. According to dual-coding theory, using text and graphics together to convey information is more effective than using either on their own. Further, the IT4IT Reference Architecture attempts to avoid using text that creates collisions between architectural layers (e.g., business function, data, and implementation layers). Level 1 introduces naming conventions for data objects that are rooted in the well-known IT frameworks and standards.

While a functional component may control one or more data object types, a single data object can only be controlled by one functional component. To communicate this visually, a notation that embeds the “controlled” data object in the functional component is used; see Figure 82.

Diagrams can be complex and require clear “visual syntax” to help the reader interpret the elements and their relationships. For that reason, the IT4IT Reference Architecture at Level 1 is depicted without data flows and a reduced set of data relationships; see Figure 7.

As a general rule, the IT4IT Data Objects are named using:

A system of record is a synonym for a system that contains and/or controls authoritative source data.

The key data objects represent the authoritative source data and/or master data for managing digital. In IT, “system of record” is a term that is commonly used as a synonym for an authoritative source system.

An important aspect of the IT4IT Reference Architecture is to define not only the data objects but the essential relationships between them. The data objects, combined with their relationships and inter-dependencies, form the “system of record fabric” for digital management (see Figure 83 and Figure 84).

Note that in this document there are no defined “reflective” relationships, where a data object can relate to other data objects of its own type; for instance, the Digital Product data object relates to all the Digital Products on which it depends, the Service Offers can represent a hierarchy of offers, or Events can relate to Events to represent correlation. A future version of the IT4IT Standard will include these relations.

Notation and Naming

Abstraction Level 1 expresses essential relationships as lines between the participating data objects. Here, the simplified and ArchiMate notation are identical; a line connecting one data object with another.

Compliance with the prescribed system of record relationship mapping will ensure end-to-end traceability operationally and financially, and ensure Digital Product model integrity can be maintained across the lifecycle. This also eliminates the confusion and collisions that result from process re-engineering efforts that frequently occur within the various IT functions.

The Digital Product Backbone data objects are key data objects in the IT4IT Reference Architecture that annotates an aspect of the Digital Product model in its planning, development, consumable, or running state. These data objects and their relationships form the Digital Product Backbone, which provides a holistic view of a Digital Product and includes the Digital Product, Product Design, Product Release, Desired Product Instance, and Actual Product Instance.

The IT4IT Standard collectively refers to all Digital Product Backbone data objects as the “Digital Product Backbone”.

The Service Offer Backbone data objects are key data objects in the IT4IT Reference Architecture that control and define the consumption of a Digital Product. These data objects and their relationships form the Service Offer Backbone and include the Offer, Subscription, Chargeback Contract, and Service Contract data objects.

The IT4IT Standard collectively refers to to all the Service Offer Backbone objects as the “Service Offer Backbone”; see Figure 85. Note that Figure 85 is an abstraction and the relation between Service Offer and Product Release is via the Product Release Blueprint.

With the above definitions of the simplified functional component, data object, and ArchiMate notation, IT4IT Level 1 can be visualized in Figure 86, which can be compared to the simplified notation in Figure 7.

Note that the Level 1 figures are abstractions, created for easy readability. This implies that not all the relations of the formal model are shown. For all the IT4IT data object relations, see the diagrams in the definition of the functional groups: Figure 35, Figure 42, Figure 52, Figure 63.

In the normative definition of value streams, scenarios are defined for which the value stream is executed. This is complemented by defining the activities that are expected to happen as part of implementing the value stream; documented as value stream stages.

Note that the value stream stages of an IT4IT Value Stream are not considered to be a sequence of activities; value streams are abstract, and not a process description.

A scenario defines a situation in which a given value stream should be triggered to add value to the overall Value Network.

The ArchiMate solution pattern for this is an “Outcome” motivational element.

A value stream stage is a refinement of the value stream, and uses the same ArchiMate solution pattern: a Value Stream data object.

A value stream stage is defined in terms of

A stakeholder is a persona or role that an organization is expected to engage in a given value stream stage.

The ArchiMate solution pattern for this is a “Business Stakeholder” motivational element.

This leads to the ArchiMate structure of the seven IT4IT Value Streams in Figure 87. For more detail, see the definitions in Chapter 5.

As described in Levels 1 and 2, data objects represent the data exchanged between functional components. At the Level 3 abstraction it is important to specify the attributes of the objects that must be present (those deemed essential) in the exchange. Here, the minimum set of attributes required to maintain the integrity of the system of record fabric is defined. These attributes also contribute to the formation of the canonical data model that underpins the IT4IT Reference Architecture. Often, IT management products will provide more information/attributes, but at Level 3 only the vendor-independent minimum that should be included is defined.

Note that the specification of a key attribute for a data object only implies that the reference architecture insists that an implementation must support the attributes. It does not specify that every instance of the data object type must have a value associated with the attribute. For example, an approval data attribute will only be filled out if the approval has happened.

The most basic key attributes are a “unique identifier” and the “data object lifecycle status”. Often there will be attributes that identify relationships to other data objects in the IT4IT model.

Notation and Naming

The ArchiMate language does not have a means to model the concept of attributes. The IT4IT Standard documents the attributes in the description of the individual key data objects. Attributes are documented as a list of name/description parts.

The naming of attributes is without prepended or appended data to the object name. So, in the Incident example above, the IT4IT Standard does not define the identifier attribute for the Incident object to be “IncidentId” or the name attribute to be “IncidentName”. It simply has attribute names such as “Id” and “Name”. If there is a need to specify the Identity (Id) of a particular data object, then the usual dot notation common in database systems is used:

The IT4IT Standard aims to reuse attribute names that denote the same thing across data object definitions to facilitate the ease of implanting systems using inheritance and to ease the management of different objects in a coherent way.

Cardinality (sometimes referred to as “multiplicity”) describes the number of allowable relations a given element can have with elements of a given other type.

For example, there is a one-to-n (1:n) relationship between “Order” and “Change” data objects. This indicates that a single order can result in multiple change requests. In the instance of a “laptop” Order, a change request might require a request for the laptop to be allocated and configured and a further change for a corporate user account to be security configured for mobile work. Therefore, one Order generated multiple Change objects, and relations must be maintained to each.

The IT4IT Reference Architecture only defines the key relationships – those that contribute to the advancement of the Digital Product lifecycle. There are other relationships that may be needed to satisfy the specific policies, processes, or capabilities but they are not considered to be part of the prescriptive guidance. Further, relationships may be maintained simply to optimize the implementation; for example, the Actual Product Instance might have a relationship back to the Digital Product data object, of which it is an instance. This relationship could be derived through the relationships across the Digital Product Backbone. The normative IT4IT Standard does not make recommendations for such optimizations.

In UML, the concept of multiplicity extends the definition/understanding/concept of cardinality by including more information on participation; i.e., what relationships must exist, or not. The IT4IT Standard does not specify multiplicity.

The IT4IT Standard only differentiates between three types of cardinality, as shown in Table 29.

Notation and Naming

The ArchiMate language does not allow the specification of cardinality in relationships, which means that cardinality is not represented in diagrams in the normative IT4IT Standard. To resolve this, data object relationships are documented in the description of the relationship in a section named “Key Data Object Relationships”.

It lists all the relations and for each in the following form:

This gives the four possible notations, illustrated with four examples from the standard:

A data flow describes the flow of information between functional components. The technique used to facilitate the flow is not specified. The reason for adding the data flow information to the Level 3 diagrams is to expose the need for integration and data sharing. It also helps to demonstrate the dependencies between functional components and how they can work together to deliver value.

The data flow arrow originates from the functional component that would normally trigger the exchange of information. This does not imply that information is only exchanged in the direction of the arrow.

An example of a data flow can be seen in Figure 88.

Figure 88 indicates a data flow of requirement data from the Requirement functional component to the Test functional component. There is also a data flow of test result data from the Test functional component to the Defect functional component. These two flows are used to maintain the relationships between the corresponding data objects.

Finally, there is a data flow from the Pipeline functional component to the Test functional component indicating that the Pipeline functional component engages with the Test functional component. The data flow indicates that a specific test needs to be triggered for execution.

As is seen in Figure 88, an arrow is used for representing data flows. As indicated, there are two types of data flow:

System of engagement data flows are marked in blue, as opposed to system of record data flows that are black.

In Level 1, key data objects and their relationships are introduced. In Level 2, how data objects are consumed or created/updated by the value streams is described. In Level 3, all the necessary key data objects and relationships are defined to form a consistent and traceable information model for managing Digital Products.

In order for the system of record relationships to be sustained over the course of the product lifecycle, integrations between functional components controlling the key data objects must be well defined. This requires that some data flows need to be “refined” into system of record integration specifications. These specifications become part of the normative IT4IT Standard.

For a data flow to be refined into a system of record integration, the following conditions must be satisfied:

The reason for defining these integrations as part of the architecture is to ensure the integrity of the system of record fabric and the service model. IT organizations are likely to implement products from multiple suppliers for their IT4IT Reference Architecture, and without this specification there is no way to ensure consistency in data flows.

A system of record integration is depicted in Figure 89. This figure provides an illustrative example that describes the state dependency between the “Event” and “Incident” data objects. Here, Events generate Incidents, which results in a relationship and dependency between these two data objects.

Relationships are also formed between functional components to enable humans and machines to interact with and/or take action on the data objects. These relationships are called “system of engagement” integrations (experience-centric integration) and are derived from value stream use-cases and user stories. They are offered as guidance rather than prescriptive practices; the intent being to demonstrate to the reader how data object relationships stimulate and/or are affected by human-to-machine and machine-to-machine interactions.

For example, the Incident to Knowledge system of engagement integration “Search Knowledge” (see Figure 65) indicates that a common use-case for managing an incident is to look up relevant Knowledge Items based on the Incident information and potentially create a link to the most relevant ones. But unlike a system of record integration we do not specify that there is a long-lived maintained relationship, such as when an incident is updated then the Knowledge Item needs to be updated, or that updates to Knowledge Items should result in updates to the related Incidents.

Notation and Naming

At Level 3, the normative notation depicts system of record integrations using a black dotted line with a solid end-arrow accompanied by the name of the data object that is transferred to create the relationship. No subsequent information is shown as being passed on an ongoing basis to maintain or update either data object. The formal notation in the ArchiMate language uses the collaboration and interaction concepts.

System of engagement integrations use blue dotted lines with a solid end-arrow, and a name that describes the type of engagement or process action responsible for triggering the integration/data flow.

Abstraction Level 4 is where the architecture becomes more Product Design and implementation-oriented. Here, for example, providers of IT management products and services can design/specify their service, interface, and exchange models, which should be derived from Level 3 content. Other examples of Level 4 content might include:

Regardless of the how the vendor chooses to adapt and implement the architecture, it must be able to be mapped back into what is specified at Levels 1 to 3.

A capability is the ability of an organization to produce an outcome of value through the utilization of people, processes, and technology. A list of capabilities with a high level of granularity is being compiled. These come from ITIL, COBIT, SAFe, PMBOK, and other industry sources. It is not the focus or intent of this document to redefine or modify existing work that has been done around such IT capabilities, but, as a non-normative work, a comprehensive list is being compiled that defines the relationships to functional components.

Capabilities can be viewed as a refinement of the Level 2 normative functional groups of the IT4IT Reference Architecture. In the solution pattern/metamodel, the functional components belong to a Level 2 group but will relate to one or several capabilities.

Note that in the IT4IT Standard, Version 2.1, and other previous IT4IT Standard versions, capabilities were named “Capability Disciplines”.

Notation and Naming

While capabilities are not part of the normative IT4IT Reference Architecture, we recommend to use the ArchiMate notation to describe them for consistency across the architecture.

In the IT4IT Reference Architecture, the essential service concept describes a means of facilitating integration between functional components or to take action on a data object; e.g., Create, Read, Update, Delete (CRUD). Essential services are typically implemented as an API, web service, or microservice with a well-defined set of parameters. The goal of essential services is to eliminate the need for point-to-point integrations between IT management products. They are defined by examining the data objects and specifying the attributes, parameters, etc.

These essential services will be used to implement the data flows and the processes that are deemed necessary to deliver optimized value streams.

Notation and Naming

Essential services can be modeled in the ArchiMate language using the “Application Service” construct. In the informal notation at Level 4 they are depicted as an oval inside a functional component element, as in the scenario example given in Figure 90.

In the IT4IT Reference Architecture, a scenario is a narrative that describes foreseeable interactions of user roles (or “actors”) and a system (or functional component). The term is analogous with “epic” or “theme” in Agile development methodologies. Scenarios are used to explain, enhance, or modify the reference architecture and are described using a structured template that includes a formal notation that can be expressed in the ArchiMate language. This enables readers to consume information more easily, as multiple organizations may produce and/or contribute to scenarios over time.

The following list is an example of the “scenario master document content”:

In the example shown in Figure 91, two views would be created: one showing an Incident Management capability and another view for the Knowledge Management capability. The view should provide more information on how the functional components are aligned with the capabilities to automate the scenario:

The full power of the ArchiMate language can be used to specify an actual current or future state implementation of the IT4IT Reference Architecture.