P1 – Resource Types

The P1, Resource Types, View specifies the types of Resources and identifies the technologies and competences required for the architecture over time. It can also be used to specify the properties of Resources and the ports exposed by technical resources. The Resources can be organised into a specialisation hierarchy. P1 provides a library of Resource Types traced back to the Capabilities and/or services they implement. These may be configurations of resources or configurations which utilise other services. In both cases, these views specify how services are implemented. They do not specify the services themselves (this is covered by the Service Specifications layer), nor do they describe deployed services (covered by the Deployed Resources layer).

Concerns Addressed

Capability Delivery.
Service Implementation.
Interface Specification.

Background

The P1 View collects together all the Resource Types in the architecture together with a depiction of their performance characteristics. P1 also provides a summary of the technologies and competencies that impact on the Resources that constitute the architecture, including descriptions of relevant:

Emerging and current technologies.
Industry trends.
Predictions (with associated confidence factors) of the availability and readiness of specific hardware and software products.
Current and possible future skills.

Technologies and competences can be set against a timeline indicating when they are forecast to be in use. P1 includes an assessment of the potential impact of these items on the enterprise. Given the future-oriented nature of this view, forecasts are typically made in short, mid and long-term timeframes, such as six, twelve and eighteen month intervals.

Usage

Identifying Resource Taxonomies.
Interface specification.
Identification of applicable protocols.
Service implementation.
Tracing business processes to the resources that support them.
Forecasting technology readiness against time.
HR trends analysis.
Recruitment planning.
Planning technology insertion.
Input to options analysis.
Definition of performance characteristics.
Identification of non-functional requirements.

Representation

Tabulation.
Mapping (matrix).
Topological – connected shapes.
UML Composite Structure Diagram.
SysML Blocks Diagram
Timeline view.
‘Herringbone’ diagram.

Detailed View Description

One of the primary purposes of the P1 View is to communicate which characteristics are considered most crucial for the successful achievement of the mission goals assigned to the resource. These performance parameters can often be the deciding factor in acquisition and deployment decisions and can be specified in terms of both qualitative and quantitative characteristics of resources.

Figure 3-435: Example P1 View

The P1 View describes the interface protocols and hardware specifications of each port on a system. P1 uses the common term ‘protocol’ as a specialisation of the NAF term ‘standard’ to describe the standards specifically used in interface and communication specifications. Any protocol referred to in a P1 diagram must be listed and defined in the A8, Standards View.

A P1 view comprises of one diagram for each system in the architecture, as shown in Figure 3-446 and Figure 3-457:

Figure 3-446: Example P1 View in UML Using Simplified Stack Notation

Figure 3-457: Example P1 Port Specification

The P1 also maps a resource (which may itself be constructed from other resources) to the services it can provide. P1 views are usually presented as a structural model (e.g. a UML composite structure), with tracing relationships to services. It is also possible to present a P1 as a table, with services on one axis and resources on the other. Care should be taken with this approach, however, as it tends to hide any underlying structure the resources might have.

A given implementation may provide a different level of service depending on the environment in which is it used. The service attributes defined in S1, Service Taxonomy, can be given values and related to the environment under which those values are true.

Figure 3-468: UML Representation of Service Provision

The P1 View also specifies how a service implementation uses other services to provide its own service(s). This is effectively a composition of services. In specifying the services the implementation requires, P1 also specifies the level of service required. Similarly, the level of service provided by the implementation will also be specified.

Figure 3-479: UML Representation of Service Implementation

The detailed meta-model and element list for P1, Resource Types, is at paragraph 4.5.1.