Concepts at Level 4 and Level 5
Level 4 and Level 5 of an IT4IT architecture are not part of the normative standard.
Level 4 is used to represent reference architectures built by vendors and system integrators as a refinement of the normative IT4IT Standard.
Level 5 is used to refine Level 4 (or Level 3) reference architectures into a concrete implementation architecture.
Levels 4 and 5 are not owned and controlled by The Open Group but by the consumers of the IT4IT Standard.
For example, vendors might add essential services to the baseline or add functional components to differentiate their product or offering. The principle to be applied here is that whatever is added should build from and add to, but not change the prescriptive model defined in Levels 1 to 3.
| In The Open Group IT4IT Forum, some examples of Level 4 and Level 5 architectures have been developed as guiding material. |
Level 4: Vendor and System Integrator Extensions
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:
-
Defining extensions to the standard: “these key attributes are being used, but these are added for the following reasons …”
-
Adding data objects: “these non-key data objects were added, and are using the same notation style to reflect how they build off the baseline architecture”
-
Additional notations: “the ArchiMate language is used for explaining scenarios and UML for the data models”
-
Introduction of process: might introduce/model practitioner-level processes within scenarios
-
Canonical data model: might introduce the vendor-specific canonical data model for their IT management products
-
Integrations: might specify the techniques/methods used in implementing system of record integrations
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.
Capabilities
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.
Essential Services
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 Scenario Process Flow Example Utilizing Two Essential Services.
Scenarios and Processes
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”:
-
Introduction: a high-level description of the scenario to be described along with the goal to be achieved
-
Requirements: model the properties of the elements that are needed to achieve the “ends” that are modeled by the goals; in this respect, requirements represent the “means” to realize goals
-
Process flow: an explanation of the process flow in the organization; this example explains how an Incident is handled using existing knowledge
-
Automation specification using the reference architecture: explains how the process is to be supported by the reference architecture
In the example shown in Essential Service Diagram Example, 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:
-
Essential services supporting the scenario; see Scenario Process Flow Example Utilizing Two Essential Services
-
Data objects and key attributes: describes the data objects that are involved and the attributes of the data objects that are needed or impacted
