1. Introduction

1.1. Objective

The Open Group IT4IT™ Standard, Version 3.0, describes a reference architecture that can be used to manage the business of Information Technology (IT) and the associated end-to-end lifecycle management of Digital Products.

It is intended to provide a prescriptive Target Architecture and clear guidance for the transformation of existing technology management practices for a faster, scalable, automated, and practical approach to deploying product-based investment models and providing an unprecedented level of operational control and measurable value.

This foundational IT4IT Reference Architecture is independent of specific technologies, vendors, organization structures, process models, and methodologies. It can be mapped to any existing technology landscape. It is flexible enough to accommodate the continuing evolution of operational and management paradigms for technology. It addresses every Digital Product lifecycle phase from investment decision-making to end-of-life.

1.2. Conformance

Refer to The Open Group website for conformance requirements for this document.

1.3. Normative References

This document contains provisions which, through references in this standard, constitute provisions of The Open Group IT4IT Standard. At the time of publication, the edition indicated was valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent edition of the standard listed below:

ArchiMate® 3.1 Specification (C197), a standard of The Open Group, November 2019, published by The Open Group; refer to: www.opengroup.org/library/c197

1.4. Terminology

For the purposes of this document, the following terminology definitions apply:


Describes a possible feature or behavior available to the user or application.


Describes a feature or behavior that is optional. To avoid ambiguity, the opposite of “may” is expressed as “need not”, instead of “may not”.


Describes a feature or behavior that is a requirement. To avoid ambiguity, do not use “must” as an alternative to “shall”.

Shall not

Describes a feature or behavior that is an absolute prohibition.


Describes a feature or behavior that is recommended but not required.


Same meaning as “shall”; “shall” is the preferred term.

1.5. Future Directions

It is expected that this document will need to be revised from time to time to remain current with both practice and technology.