overarching it architecture principles for the public …architecture principles version 2.1 page 5...

Overarching IT architecture

principles for the public sector

Version 2.1 Agency for Public Management and eGovernment

17 September 2012

Architecture principles version 2.1 of 13 17.9.2012

Content About the principles ................................................................................................................... 3

Service orientation .................................................................................................................... 4

Interoperability ......................................................................................................................... 5

Accessibility ................................................................................................................................ 7

Security ...................................................................................................................................... 9

Transparency ........................................................................................................................... 11

Flexibility .................................................................................................................................. 12

Scalability ................................................................................................................................. 13


About the principles

Introduction User orientation and cost efficiency are two important considerations within public services.

To support this, the government has, by presenting the eGovernment Program – På nett med

innbyggerne and Meld. St. 19 (2008-2009) - Ei forvaltning for demokrati og fellesskap,

decided on seven overarching IT architecture principles.

The principles will function as a set of common guidelines for the use of IT in the public

sector. They will help ensure that IT solutions are properly aligned with work processes in the

public administration, thereby enabling better public services.

The principles are mandatory for government agencies and shall be applied when new IT

solutions are developed or when significant modifications are made to existing IT solutions. If

the principles lead to significant undesirable consequences, they can be partially or

completely waived. Deviations of this kind must be documented. The principles are

recommended for use in the municipal sector.

Version 2.1 of the architecture principles is mainly a clarification of the previous version, 2.0.

The most significant change is the new structure, which will make it easier to get an overview

of each principle. Difi will continue to develop the architecture principles in collaboration

with stakeholders in the public sector.

The relationship between the enterprise and the architecture principles Enterprise architecture deals with how an enterprise is organised, how business processes are

put together and how IT solutions are utilized to support those processes. An enterprise

architecture consists of principles, methods and models, which together describes this as a

whole. A well documented and unified enterprise architecture helps ensure that individual

solutions are realised in a larger context, facilitating alignment both with business processes

and existing IT solutions.

Difi has recommended that the overarching architecture principles are included in a common

enterprise architecture for the public sector.1 Difi is responsible for managing and developing

the architecture principles. The respective sectors and public bodies are responsible for

incorporating the architecture principles into their own architecture.

Target audience The target audience for the architecture principles is primarily architects. They must ensure

that the principles are incorporated into policies and principles, and that they become part of

the architecture of the enterprise.

The principles are also relevant for employees who own, manage or develop public services.

1 Difi, 2010: Report 2010:17 – National common components in the public sector


Service orientation

Principle

Functionality and performance should be the main considerations when

developing IT solutions. IT services that are necessary to support all or

parts of one or several business processes, must be identified.

Explanation

The principle should support strategic, efficient and cost-effective use

of IT by taking into account the services (regarding functionality)

delivered by a component, rather than the composition of the

component itself. This contributes to breaking up silos, both within

agencies and across sectors, which in turn facilitates re-use.

Components can be national or sector based common components, or

they can be components specific to an agency.

By facilitating re-use of services and components in agencies and

across the public sector, when appropriate, the principle of service

orientation adds to faster and more cost effective development of

digital services.

Consequences

When establishing or further developing IT solutions, the agency

should adopt an approach that ensures alignment and coherence with

the agency's task.

In order to maintain the principle of service orientation, the agency

should ensure that IT solutions and their components are sufficiently

modularised, loosely coupled and use of well-defined interfaces.

In order to ensure re-use, the agency should:

Consider if there are IT solutions or components which can be

re-used

Consider if the entire IT solution or some of the components

are relevant for other parts of the public sector


Interoperability

Principle

The agency and its IT solutions must, when needed, be able to interact

with other relevant agencies and their IT solutions at an expedient

level.

Explanation

The principle should facilitate a more efficient information flow and

ensure that the overall IT development in the public sector supports

business processes and regulations, both within the individual agency

and across the public sector.

The principle distinguishes between three different types of

interoperability:

Organisational interoperability

Involves coordination of business processes, contractual

frameworks and changes in organisational conditions necessary

for interaction

Semantic interoperability

Involves clarifying the meaning of the information elements

that are exchanged

Technical interoperability

Involves using technical standards that facilitate well-defined

interfaces, transmission protocols and formats

It is a prerequisite for interoperability that the interaction is not in

conflict with legal regulations. Legal assessments are central as part of

both organisational and semantic interoperability.

Consequences

The need for interaction, and the consequences this has for

organisational, semantic and technical interoperability, should always

be assessed when establishing or further developing IT solutions. The

need for future interaction should also be considered.

In order to achieve satisfactory interaction, it is necessary to take into

account all the different types of interoperability. Which types should

be emphasised and to what degree, will be situational and must be

considered by the individual agency. The topics below are a starting

point for the considerations:

Organisational interoperability

Agencies involved in the interaction must clarify legal

regulations, financial models and service level agreements.

Business goals, roles, resources, responsibilities and

requirements must be clarified and reconciled


Semantic interoperability

Common conceptual and information models within the

relevant area of interaction should be considered coordinated.

Conceptual and information models must be reconciled with

legal regulations, so the coordination of terms doesn't override

the legislator's intent

Use of standards

Choice of organisational, semantic and technical standards

shall be based on Referansekatalog for IT-standarder i

offentlig sektor (Reference catalogue for IT standards in the

public sector). Open standards should be used in cases where

the reference catalogue does not mention relevant standards


Accessibility

Principle Digital services should be available when the users need them, easy to

find, and with a user friendly and universal design.

Explanation

The principle shall facilitate user friendly digital services by ensuring

that the services are accessible to the intended users in a timely

fashion, in a way that arrange for ease of use.

The services should be accessible to all relevant user groups, regardless

of age, gender, functional ability and cultural or ethnic background. No

user group shall be discriminated.

The accessibility principle is particularly relevant for public services.

Consequences

Public services must be in accordance consistent with Lov om forbud

mot diskriminering på grunn av nedsatt funksjonsevne

(diskriminerings- og tilgjengelighetsloven), and other relevant

legislation.

In addition, the following elements should be considered when

developing new digital services:

Choice of standards

Choice of standards shall be based on Referansekatalog for IT-

standarder i offentlig sektor (Reference catalogue for IT

standards in the public sector) and must be in accordance with

Forskrift om IT-standarder i offentlig forvaltning. Open

standards should be used in cases where the reference catalogue

does not mention relevant standards

Service delivery

The service must be available through the relevant channels

(PC, mobile phone, tablet, etc.), but still be predictable and

recognizable

Publishing

The digital services must be easy to find and shall not require

users to know how the public sector is organized

Language adaptation

The services should be available in the target groups' language


Opening hours

The availability of digital services must be based on user needs.

This could be 24-hours a day, certain times of the day or certain

times of the year (e.g. tax return). The opening hours applies to

the accessibility of the digital service, and does not mean 24/7

case processing

Technology independence

As far as possible, the services should be technology and

platform independent, in order to avoid the need for specific

solutions or products in order to use the services

In order to ensure alignment between service design and the needs and

usage patterns of the users, relevant user groups should be involved in

development, testing and implementation.


Security

Principle

The IT solution itself and the information processed in the solution,

should, based on formal and risk based requirements, be protected

against breaches of confidentiality, integrity and accessibility.

Explanation

The security principle shall ensure that public IT solutions are

developed and operated in a secure manner, and at the same time

ensure that information and services are available to those who need

them and have the right to use them. The principle will also contribute

to strengthening the public sector's awareness concerning information

security.

The security principle is an important prerequisite for maintaining the

public's confidence in the public sector. The principle can be inferred

from legal regulations, e.g. eForvaltningsforskriften,

personopplysningsloven and sikkerhetsloven.

Any digital service that is established, shall have a defined security

level (classification), based on a risk analysis. The service shall be

designed in a manner that allows for changing the security level as

needed. The security level must be documented, ensuring that those

who use the solution, know which requirements have been fulfilled.

Confidentiality requirements shall be met. Information must be

properly protected from access by unauthorized parties.

Integrity shall be maintained. Information must be adequately

protected from accidental or unauthorized changes. Generally, it must

be possible to track who made changes and when the changes were

made.

Information shall be accessible according to defined service levels and

to users which are eligible to access the information. The access

control must balance the need for user friendliness against the need for

confidentiality.

When essential for maintaining the public's confidence in the public

sector, the security principle can limit other principles.

Consequences

The agency must identify relevant requirements for information

security as required by regulations, directives and agreements with

third parties, and document that the IT solution fulfil these

requirements.

The agency must also:

Identify what information the solution will process


Define an acceptable risk level

Conduct a risk analysis of the solution, based on the agency's

needs and characteristics

Assign an appropriate security level to the solution

Implement security measures for the IT solution, which ensure

that the assigned security level is met

Verify that the security measures work as expected

It must be possible to change the security level of the IT solution when

needed.

The agency must consider if, and if so, how, the security principle

limits any of the other architecture principles.

Regardless of this principle, there are both general and sector specific

legal regulations with which the individual agency must comply.

Specific requirements for the implementation are found in both legal

regulations, standards for information security and certification

programs.


Transparency Principle The IT solutions' functionality and data sources shall be accounted for.

Explanation

The principle shall support the rule of law by ensuring that the basis for

decisions making processes is known.

This is particularly relevant for IT solutions that act as decision support

systems, and that have implications for the rights and duties of the

individual.

Consequences

In order to underpin the principle of transparency, IT solutions shall be

developed in a manner that facilitates documented and traceable

decisions. This means that the manager of the IT solution must be able

to account for the data sources used and how any legal regulations are

applied.

Requirements for use of standards are described as part of the

principles of interoperability and accessibility.


Flexibility

Principle

IT solutions shall be designed in such a way that they do not pose as

barriers against changes in business processes, content, organisation,

ownership and infrastructure.

Explanation

The principle shall contribute to cost efficiency by ensuring that IT

solutions can be adapted to meet new requirements.

The business needs of the agency shall be the main concern in the

establishment of new IT solutions. The principle should be understood

with that in mind, and is about developing IT solutions that do not

become inoperable or need excessive modifications if there are

changes in business processes, content, organisation, ownership or

infrastructure. This facilitates re-use within the individual agency and

across the public sector.

Consequences

Services must be defined at an appropriate level. IT solutions and the

components they consist of, must be sufficiently modularised. An

appropriate modularisation is important in order to achieve flexibility

and to facilitate for maintenance and further development. In addition,

it increases the likelihood that the IT solution, or some of its

components, may be re-used by other public agencies.

Organisational conditions significant to the IT solutions, for example

service level agreements, licensing agreements or end user support,

must be possible to alter when needed.

The governance processes must be able to identify and handle needs

for change.

The degree of flexibility and what dimensions to emphasise, must be

evaluated based on the expected needs for change and assumed

additional costs.


Scalability Principle IT solutions must be able to scale according to use.

Explanation

The principle shall contribute to awareness of the importance that IT

solutions that still can be used, even though the degree of utilisation

changes. Changes can be related to the number of users, volume,

response times or the life cycle of the IT solution.

Consequences

IT solutions and the components they consist of, must be modularised

to such an extent that it is possible to up- or downscale the entire IT

solution or individual components.

Upscaling and downscaling must be possible after the IT solutions are

put into production, so that over time, they are able to deliver the

required level of performance.

Organisational conditions relevant to managing changes in utilisation

or usage patterns, must be possible to scale up or down. Examples can

be service level agreements, licensing agreements or end user support.

The governance processes must be able to identify and handle needs

for up- and downscaling.

overarching it architecture principles for the public …architecture principles version 2.1 page 5...

Documents