Introduction to Public Framework Modelling Language

In short

The language describes the architecture of a public institution. It starts from policy intent and legal basis and runs through public services, information and applications. It then reaches software delivery, runtime, hosting, operations and service continuity. A model shows, for example, which applications support a public service and what alternative the service has when those applications fail.

The language has 12 layers. Ten form the chain above. The other two cut across it: implementation, meaning the projects that change the architecture, and cross-cutting concepts such as requirements, decisions and risks. Elements are connected through 21 relationship types. For each relationship type, the language fixes between which element types it is permitted, and the application checks these rules automatically.

Models are created and checked with the Public Framework Modeller application. Each model is a file with the .pfmodel extension, which also contains its sheets.

What it is not

The language is not a legal certification. A valid model shows that the description follows the rules of the language, not that the institution complies with the law. Nor is it a project methodology: it describes the architecture and how it changes, but does not prescribe how a project is run.

Purpose and scope of the specification

The specification establishes Public Framework Modelling Language, version 1.0. It defines:

• the layers of the language and what each describes;
• the element types and their fields;
• the relationship types and the permitted combinations between element types;
• the notation, meaning how elements and relationships are drawn;
• the file format and the form of identifiers;
• the validation rules and what a conforming model means.

The specification describes the language as implemented by the Public Framework Modeller application. The annexes are generated from the application code: from the metamodel, the validation rules and the help texts. An automated test checks, at every build, that the annexes match their source. The application interface is explained separately, in the User Guide.

Who reads what

• Decision-maker, manager: what the standard covers, why it is useful and which European standards it supports — the introduction and the layers.
• Architect, analyst, consultant: how to model correctly — the layers, concepts, relationships, notation and rules.
• Tool implementer, integrator: the exact format — types, fields, permitted relationships, identifiers and rules.

The example accompanying the documentation is the “Family support benefit” model, included in the application. It describes the family support benefit of a social benefits agency and covers all 12 layers. Names in the example are in English, as they appear in the application.

What it builds on

The language takes concepts from public European standards. For example, the legal resource has a field for the European Legislation Identifier (ELI), and the interoperability agreement has a field for the level in the European Interoperability Framework (EIF). The mapping to each standard and its limits are described in chapter 7 of the specification.

Conventions

Requirements use five normative terms: “must” and “must not” mark a mandatory requirement, “should” and “should not” a recommendation whose deviation is justified, and “may” a permitted option. A requirement has a stable identifier of the form PFML-GROUP-NR, for example PFML-ID-01, which does not change after publication.

Each layer, element type and relationship type has a Romanian name, shown by the application, and a technical name, used in the model file. On first mention, the technical name follows in brackets: public service (PublicService), “has legal basis” (legalBasis). A layer is named by its name and code, for example Strategy & Public Policy (STR), and then by its code alone.