d02.01 - eira change management process · web viewinteroperability specifications (iop specs) are...

XYZ Solution Architecture Template (SAT)

of 24

This deliverable was prepared by:

Insert the company name of delivrable creator here.

ArchiMate® and TOGAF® are registered trademarks of The Open Group.ArchiMate© and TOGAF© are copyright of The Open Group. All rights reserved. Archi® is a registered trademark of Phillip Beauvoir.

of 24

TABLE OF CONTENTS1 INTRODUCTION................................................................................................................................................. 5

1.1 PURPOSE OF THIS DOCUMENT.......................................................................................................................................51.2 LIST OF ACRONYMS USED IN THIS DOCUMENT..................................................................................................................5

2 GOAL, DESCRIPTION AND TARGET AUDIENCE....................................................................................................6

2.1 GOAL.......................................................................................................................................................................62.2 WHAT IS XYZ............................................................................................................................................................62.3 WHAT IS A SOLUTION ARCHITECTURE TEMPLATE (SAT)......................................................................................................62.4 TARGET AUDIENCE......................................................................................................................................................7

3 XYZ INTEROPERABILITY MAPPED TO THE EIRA...................................................................................................8

3.1 ARCHIMATE MOTIVATION EXTENSION............................................................................................................................83.2 HOW TO USE THIS SAT...............................................................................................................................................93.3 HIGH LEVEL OVERVIEW.............................................................................................................................................113.4 LEGAL VIEW............................................................................................................................................................123.5 ORGANISATIONAL VIEW............................................................................................................................................133.6 SEMANTIC VIEW......................................................................................................................................................143.7 TECHNICAL VIEW – APPLICATION................................................................................................................................153.8 TECHNICAL VIEW – INFRASTRUCTURE...........................................................................................................................16

4 REFERENCES.................................................................................................................................................... 17

4.1 LEGISLATIVE REFERENCES...........................................................................................................................................174.2 ORGANISATIONAL REFERENCES....................................................................................................................................174.3 SEMANTICAL REFERENCES..........................................................................................................................................174.4 TECHNICAL REFERENCES.............................................................................................................................................17

5 ACKNOWLEDGEMENTS.................................................................................................................................... 18

APPENDIX: HIGH-LEVEL OVERVIEW........................................................................................................................... 19

APPENDIX: LEGAL VIEW............................................................................................................................................ 20

APPENDIX: ORGANISATIONAL VIEW......................................................................................................................... 21

APPENDIX: SEMANTIC VIEW..................................................................................................................................... 22

APPENDIX: TECHNICAL VIEW – APPLICATION............................................................................................................ 23

APPENDIX: TECHNICAL VIEW – INFRASTRUCTURE.....................................................................................................24

of 24

How to use this template?

This is a template for an SAT (Solution Architecture Template). It contains the basic structure that each SAT should follow and it provides guidance on which information to include in the different sections of the document.

The template provides guidance by including the standard text and document structure using black text without any decoration. The guiding text (text that gives an explanation and which should be removed from the final document) and placeholders (text that should be adapted by the information that is specific for your SAT) are provided in red coloured text using an italic font decoration (like this specific chapter). The proposed text and default text are of course not restrictive and the author of the SAT should adapt and enrich the proposed text to his needs.

of 24

1 INTRODUCTION

This document contains the description for a Solution Architecture Document (SAT) for XYZ.This SAT is based on EIRAva.b.c Verify EIRA version number

The ArchiMate® source are embedded in this document in the “Archi format” as well as in “The Open Group ArchiMate Model Exchange File Format”.Insert two files here

1.1 Purpose of this documentEnterprise and Solution architects can use this document to design solution architectures in the domain of XYZ.

1.2 List of acronyms used in this documentTable 1-1

ABB Architecture Building BlockEIRA© European Interoperability Reference ArchitectureSAT Solution Architecture TemplateSBB Solution Building Block… …

of 24

2 GOAL, DESCRIPTION AND TARGET AUDIENCE

This chapter gives the goals and a description on XYZ and indicates the target audience and their potential use of this Solution Architecture Template (SAT).

2.1 GoalThe purpose of this SAT is to provide guidance by defining a minimal, but holistic (legal, organisational, semantic and technical) interoperability architecture in the domain of XYZ. This SAT should allow businesses, citizens and public administrations to have a common understanding of the most-salient building blocks.

2.2 What is XYZInsert a short description of the target area of this SAT here.

This description should give the reader of the SAT an overview of the context, the domain that is covered by this SAT. This description should be high-level, not going into details, since this will be done in the different views of the SAT.

2.3 What is a solution architecture template (SAT)A Solution Architecture Template (SAT) is a specification extending the EIRA© providing support to solution architects in a specific solution domain. An SAT contains a motivation (principles, requirements), a goal and a description of the supported functionalities, a sub-set of the EIRA© core Architecture Building Blocks (ABBs) covering the four views, a set of specific ABBs extending EIRA©'s views enabling specific functionalities to be provided by implementations derived from the SAT and the interoperability specifications of selected ABBs and a narrative for each EIRA© view. The benefits of a SAT are the following:

Provides architects with a common approach to cope with a specific interoperability challenge. It also places the focus on the key-points you need to consider.

An architect can create a solution architecture by mapping existing Solution Building Blocks (SBBs) to an SAT, based on the interoperability specifications that are provided. This is done by providing SBBs for the ABBs identified in the SAT.

When an architect creates an SAT, he/she can define the interoperability specifications for the SAT’s ABBs and moreover recommend specific SBBs which produces faster and more interoperable results.

An SAT can be created within and across the different views of the EIRA©. An SAT can then support architects specialised in different interoperability levels."

of 24

2.4 Target audienceThis document has the following target audience: The audience should be taken into account based on the use-case that you have in mind when developing this SAT, each use-case potentially has a different audience. Additionally, the list below serves as example and starting point and should be adapted according to your needs.

Table 2-2

Audience Description

Architect Enterprise/solution architects in the need of understanding, implementing, or describing an XYZ solution.

Policy maker Policy makers studying the implications due to policy changes in the area of XYZ

Public Administration / Members States

Public Administrations of the European Union that need to have a holistic view of the XYZ interoperability architecture

of 24

3 XYZ INTEROPERABILITY MAPPED TO THE EIRA© This chapter contains for each EIRA© view the corresponding ArchiMate® model and narrative. Next to the SAT’s EIRA© architecture building blocks, the ArchiMate® model includes, where applicable, the related specifications, principles and requirements.The models have been scaled down to fit with the text, they are included in bigger format in the appendix.

3.1 ArchiMate® motivation extensionKeep this paragraph if the motivation extension of ArchiMate® is used, remove otherwise.

The motivation extension is used to model specific goals, principles, requirements and/or constraints and optionally also the sources of those intentions; stakeholders, drivers and assessments. Motivational concepts are used to model the motivations, or reasons, that underlie the design or change of some enterprise architecture. These motivations influence, guide, and constrain the design.

It is essential to understand the factors, often referred to as drivers, which influence the motivational elements. They can originate from either inside or outside the enterprise. Internal drivers, also called concerns, are associated with stakeholders, which can be some individual human being or some group of human beings, such as a project team, enterprise, or society.

The actual motivations are represented by goals, principles, requirements, and constraints. Goals represent some desired result – or end – that a stakeholder wants to achieve; e.g., increasing customer satisfaction by 10%. Principles and requirements represent desired properties of solutions – or means – to realize the goals. Principles are normative guidelines that guide the design of all possible solutions in a given context.1

In addition to the standard EIRA© concepts, the diagrams use the following concepts coming from the ArchiMate® motivation extension

Table 3-3

Non-EIRA© concept Description

A principle is defined as a normative property of all systems in a given context.

A requirement is defined as a statement of need that must be realized by a system.

A goal is defined as an end state that a stakeholder intends to achieve.

A constraint is defined as a restriction on the way in which a system is realized.

1 http://pubs.opengroup.org/architecture/archimate2-doc/chap10.html

of 24

http://pubs.opengroup.org/architecture/archimate2-doc/chap10.html

A stakeholder is defined as the role of an individual, team, or organization (or classes thereof) that represents their interests in, or concerns relative to, the outcome of the architecture.

A driver is defined as something that creates, motivates, and fuels the change in an organization

An assessment is defined as the outcome of some analysis of some driver.

… …

The following principles, requirements, goals and constraints, linked to the following stakeholders, drivers and assessments are used in this SAT:

A Principle : A short description of the principle

…

A Requirement : A short description of the requirement

…

A Goal: A short description of the goal

…

A Constraint: A short description of the constraint

…

A Stakeholder: A short description of the stakeholder

…

A Driver: A short description of the driver

…

A Assessment: A short description of the assessment

…

3.2 How to use this SATAn architect that uses this SAT typically wants to perform a gap-analysis between an existing solution and this Solution Architecture Template, or he/she wants to model a solution in the domain of XYZ and uses this document as guidance.

3.2.1 Gap AnalysisUsing this SAT for gap analysis, the architect can map the building blocks of the solution to the ones in this SAT and identify which building blocks are missing. These building blocks can either indicate missing functionality or missing interoperability specifications.

of 24

3.2.2 Building a solutionWhen building a solution, the architect is expected to use the five different EIRA© views and provide a solution in the form of Solution Building Blocks (SBBs) for the Architecture Building Blocks (ABBs) that are indicated. This is done by replacing the Architecture Building Block (ABB) with an annotated Solution Building Block. The existing Solution Building Blocks (SBB) in this SAT should not be removed and replaced, however, the acknowledgement of reusing these building blocks can be done by removing the ABBs which they specialise. Interoperability Specifications (IoP specs) are added as specialisation of an Interoperability ABB, implemented in the form of an SBB and attached to an ABB as interoperability requirements. The final solution should only contain the implementation (the SBB) of the IoP SpecThe result will be a solution architecture that will contain only SBBs, all ABBs should have been removed (in the case this SAT already provides SBBs for this ABB) or replaced by SBBs (solutions that implement that ABB).

The SAT is a document describing the needed Architecture Building Blocks for a desired solution. This should not be taken as restrictive but as advisory. When an Architecture Building Block (ABB) is present for which there is no implementation foreseen in the form of a Solution Building Block (SBB), it is strongly recommended, but not mandatory, to take this ABB into consideration in the final solution.

of 24

3.3 High Level viewpointThe High-level viewpoint of this SAT contains the focal EIRA© Architecture Building Blocks (ABBs) of each view and consists of the following sub-set of ABBs:Insert a picture of the high level viewpoint here.

Narrative explaining the content of the viewpoint.

The EIRA© high-level viewpoint, visualises the focal architecture building blocks of each view. It provides an introductory overview of the most important EIRA© ABBs.

The ABBs included in the high-level viewpoint represent the points that link the EIRA©’s views enabling traceability between their different building blocks. As such they should be considered as key elements of any interoperability solution, reference architecture or solution architecture template. They are not necessarily mandatory but should always be considered by a user of the EIRA© when executing one of its use cases.

The author of this SAT should look at the EIRA© high-level overview and apply each of the building blocks of this view to the SAT. It is expected that most of the building blocks of the EIRA© high-level viewpoint also appear in the SATs high-level viewpoint.

The following focal building blocks are expected to be modelled:

Public Policy

Public Service

Public Service Consumer

Public Service Provider

Business Capability

Business Information Exchange

Business Information

Data

Representation

Machine to Machine Interface

Human Interface

Choreography service

Orchestration service

Application Service(s)

Digital Service Infrastructure

Hosting and Network Infrastructure Service

Interoperability specifications are typically omitted from the High-Level viewpoint, in order to keep this view clear, the interoperability specifications are added to the specific EIRA© views.

of 24

3.4 Legal ViewThe Legal view of this SAT consists of the following sub-set of EIRA© Architecture Building Blocks (ABBs) as well as a number of predefined Solution Building Blocks (SBBs):Insert a picture of the legal view here.

Narrative explaining the content of the view.

The Legal view models the most important public policy development enablers and implementation instruments that shall be considered in order to support legal interoperability. When creating an SAT, the author should document all “legal requirements or constraints” as well as “operational enablers” as part as “public policy formulation instruments”, documents that are used to realise a public policy. In case that these legal documents are on EU level, but applicable on national level, you should model them as Legal requirements and constraints, as well as legal interoperability specifications. This implies that the references will appear twice, but their purpose is not the same.

The following building blocks are expected to be modelled:

Public Policy

Binding instrument

Non-Binding instrument

We also expect “Interoperability Specifications” to be modelled for most of the building blocks.

of 24

3.5 Organisational ViewThe Organisational view of this SAT consists of the following sub-set of EIRA© Architecture Building Blocks (ABBs) as well as a number of predefined Solution Building Blocks (SBBs):Insert a picture of the organisation view here.


The Organisational view models the most important building blocks that shall be considered in order to support organisational interoperability among providers and users of a public service.

The following building blocks are typically found in an organisational view. You can expect to find the actors that play a role in the provisioning or consumption of the public service. These actors are either citizens, business or organisations. The public service often has some sort of agreement on the service that is being offered. This agreement can be official, like a service level agreement, or on an informal base.

The public service is realised by one or more business capabilities that have a business information exchange (between the provider and the consumer of the public service) with a specific kind of business information.


Interoperability agreements

Public Service Provider

Public Service Consumer

Service Delivery Model

Public Service

Business Capability

Business Information Exchange

Business Information


of 24

3.6 Semantic ViewThe Semantic view of this SAT consists of the following sub-set of EIRA© Architecture Building Blocks (ABBs) as well as a number of predefined Solution Building Blocks (SBBs):Insert a picture of the semantic view here.


The Semantic view models the most important building blocks that should be considered in order to support semantic interoperability of information exchanges between administrations, businesses and citizens.


Representation

Data

Data Standard


Depending on the type of Data, you can either use Data as building block, or you can chose to use a more specialised building block to represent your data (for instance: transactional data or reference data). The same applies to Data Standards, you can either chose to use a Data Standard as building block, or use a more specific implementation like Data models or identifier schemes.

of 24

3.7 Technical View – ApplicationThe Technical application view of this SAT consists of the following sub-set of EIRA© Architecture Building Blocks (ABBs) as well as a number of predefined Solution Building Blocks (SBBs): Insert a picture of the technical view - application here.


The Technical - Application view contains the most important application building blocks that need to be considered in order to support technical interoperability when building an Interoperable European Solution. An Interoperable European Solution can support one or more public policies.


One or more application services

Machine to Machine Interface

Human Interface

Choreography service

Orchestration service


of 24

3.8 Technical View – Infrastructure The Technical infrastructure view of this SAT consists of the following sub-set of EIRA© Architecture Building Blocks (ABBs) as well as a number of predefined Solution Building Blocks (SBBs):Insert a picture of the technical view - infrastructure here.


The Technical - Infrastructure view provides an architecture content metamodel for the most important cross-sectorial infrastructure services, along with the supporting hosting and networking facilities, which shall be considered in order to support technical interoperability when building an Interoperable European Solution. The difference with the application part of the Technical view is that the building blocks in the infrastructure view are considered to be relevant for solutions in any sector of government.


Digital Service Infrastructure

Hosting and Network Infrastructure Service


of 24

4 REFERENCES

European Interoperability Reference Architecture (EIRA ©)https://joinup.ec.europa.eu/asset/eia/

The New European Interoperability Framework (EIF)https://ec.europa.eu/isa2/eif_en

ArchiMate®http://www.opengroup.org/subjectareas/enterprise/archimate

Archi®http://www.archimatetool.com/

A reference

A reference link

…

4.1 Legislative references A reference

A reference link

…

4.2 Organisational references A reference

A reference link

…

4.3 Semantical references A reference

A reference link

…

4.4 Technical references A reference

A reference link

…

of 24

http://www.archimatetool.com/






http://www.opengroup.org/subjectareas/enterprise/archimate

https://ec.europa.eu/isa2/eif_en

https://joinup.ec.europa.eu/asset/eia/

5 ACKNOWLEDGEMENTS The creation of this SAT was made possible with the help of XYZ. We would like to thank the following people for their input (alphabetical order):

LAST NAME, First Name

…

of 24

APPENDIX: HIGH-LEVEL OVERVIEWInsert readable and scalable (for example, based on SVG or WMF) picture of the high-level overview here. This picture already appears in the third chapter of this template, but is repeated here in a more readable version.

of 24

APPENDIX: LEGAL VIEWInsert readable and scalable picture (for example, based on SVG or WMF) of the legal view here. This picture already appears in the third chapter of this template, but is repeated here in a more readable version.

of 24

APPENDIX: ORGANISATIONAL VIEWInsert readable and scalable picture (for example, based on SVG or WMF) of the organisational view here. This picture already appears in the third chapter of this template, but is repeated here in a more readable version.

of 24

APPENDIX: SEMANTIC VIEWInsert readable and scalable picture (for example, based on SVG or WMF) of the semantic view here. This picture already appears in the third chapter of this template, but is repeated here in a more readable version.

of 24

APPENDIX: TECHNICAL VIEW – APPLICATION Insert readable and scalable picture (for example, based on SVG or WMF) of the technical view - application here. This picture already appears in the third chapter of this template, but is repeated here in a more readable version.

of 24

APPENDIX: TECHNICAL VIEW – INFRASTRUCTURE Insert readable and scalable picture (for example, based on SVG or WMF) of the technical view - infrastructure here. This picture already appears in the third chapter of this template, but is repeated here in a more readable version.

of 24

d02.01 - eira change management process · web viewinteroperability specifications (iop specs) are...

Documents