XYZ Solution Architecture Template (SAT)

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.

TABLE OF CONTENTS

1Introduction

1.1Purpose of this document

1.2List of acronyms used in this document

2Goal, description and target audience

2.1Goal

2.2What is XYZ

2.3What is a solution architecture template (SAT)

2.4Target audience

3XYZ interoperability mapped to the EIRA

3.1ArchiMate motivation extension

3.2How to use this SAT

3.3High Level Overview

3.4Legal View

3.5Organisational View

3.6Semantic View

3.7Technical View – Application

3.8Technical View – Infrastructure

4References

4.1Legislative references

4.2Organisational references

4.3Semantical references

4.4Technical references

5Acknowledgements

APPENDIX: High-level overview

APPENDIX: Legal view

APPENDIX: Organisational View

APPENDIX: Semantic View

APPENDIX: Technical View – Application

APPENDIX: Technical View – Infrastructure

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 restrictiveand the author of the SAT should adapt and enrich the proposed text to his needs.

1Introduction

This document contains the description for a Solution Architecture Document (SAT) for XYZ.

This SAT is based on EIRAva.b.cVerify 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.1Purpose of this document

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

1.2List of acronyms used in this document

Table 1-1

ABB / Architecture Building Block
EIRA© / European Interoperability Reference Architecture
SAT / Solution Architecture Template
SBB / Solution Building Block
… / …

2Goal, 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.1Goal

The 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.2What is XYZ

Insert 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.3What 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."

2.4Target audience

This 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-1

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 XYZinteroperability architecture

3XYZinteroperability 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.1ArchiMate® motivation extension

Keep 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-1

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.
/ 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.2How to use this SAT

An 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 ofXYZ and uses this document as guidance.

3.2.1Gap Analysis

Using 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.

3.2.2Building a solution

When 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 Spec

The 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.

3.3High Level viewpoint

The High-levelviewpoint 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.

3.4Legal View

The 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.

3.5Organisational View

The 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.

Narrative explaining the content of the view.

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.

The following building blocks are expected to be modelled:

  • Interoperability agreements
  • Public Service Provider
  • Public Service Consumer
  • Service Delivery Model
  • Public Service
  • Business Capability
  • Business Information Exchange
  • Business Information

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

3.6Semantic View

The 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.

Narrative explaining the content of the view.

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.

The following building blocks are expected to be modelled:

  • Representation
  • Data
  • Data Standard

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

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.

3.7Technical View – Application

The 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.

Narrative explaining the content of the view.

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.

The following building blocks are expected to be modelled:

  • One or more application services
  • Machine to Machine Interface
  • Human Interface
  • Choreography service
  • Orchestration service

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

3.8Technical 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.

Narrative explaining the content of the view.

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.

The following building blocks are expected to be modelled:

  • Digital Service Infrastructure
  • Hosting and Network Infrastructure Service

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

4References

  • European Interoperability Reference Architecture (EIRA ©)
  • The New European Interoperability Framework (EIF)
  • ArchiMate®
  • Archi®
  • A reference

A reference link

  • …

4.1Legislative references

  • A reference

A reference link

  • …

4.2Organisational references

  • A reference

A reference link

  • …

4.3Semantical references