Metamodell Teknik
Beskrivning | Arkitektur-perspektiv | Verksamhets-område | Publicerad / Version |
|---|---|---|---|
Metamodell med element och relationer för beskrivning av applikations- och teknikarkitektur. | Teknik |
| 2022-12-08/137 2019-12-12/128 |
Innehållsförteckning
Versionshistorik
Metamodellen för applikationslagret och tekniklagret definierar de begrepp som kan användas för att beskriva arkitekturen på dessa två nivåer. Metamodellen innehåller beskrivningar av begreppen i sig och hur de förhåller sig till varandra, men även hur de förhåller sig till begrepp i arkitekturgemenskapens övriga metamodeller. Metamodellen täcker både in strukturell och dynamisk beskrivning.
Ansatsen har varit att så långt som möjligt använda etablerade begrepp och relationer, men samtidigt förenkla dessa så att metamodellen blir relevant och fungerar som en konkret guide för hur arkitektur ska beskrivas på denna nivå. Gör man metamodellen för rik fungerar den inte som guide och kraft för att ensa arkitekturbeskrivningar. Gör man den å andra sidan för fattig kommer den inte att vara tillräcklig för att användas i alla sammanhang.
Arbetet har framför allt utgått från TOGAF, Archimate och UAF, men även tittat på andra standarder och referenser som exempelvis EIRA och OASIS SOA Reference Model. De refererade standarderna och arbetena finns bilagda under avsnittet Arbetsmaterial.
Modelldiagram
Elementdefinitioner
Element | Definition | Exempel | Vägledning | Källor |
|---|---|---|---|---|
Applikationsrelaterade element | ||||
Definitionen motsvarar termen: applikationskomponent | självständig komponent som utför en eller flera applikationsfunktioner
Applikationens funktionalitet tillgängliggörs via ett eller flera applikationsgränssnitt. | Logiska: Journalsystem, som kan brytas ner i (komponenter), ex:
Fysiska:
| En applikation kan vara allt från en liten och enkel mobilapp till ett stort och komplext affärssystem. Huruvida en stor och komplex applikation är att anse som en eller flera applikationer är upp till arkitekten att avgöra. I en vy över affärssystemet kan det delas upp i skilda applikationer (-komponenter), samtidigt som det i en vy över hur det integreras kan beskrivas som endast en applikation. En applikation kan bestå av applikationskomponenter. En applikation ska kunna implementeras fristående. Den utför en eller flera applikationsfunktioner och exponerar endast funktionalitet via en uppsättning applikationsgränssnitt. I ett tidigt utvecklingsskede är logisk (konceptuell) applikation användbar. En logisk applikations namn ska helst vara ett substantiv och används främst för att definiera mönster, exempelvis i referensarkitekturer, eller som element i övergripande målarkitekturer och sammanfattningar. Det är också lämpligt att använda i upphandlingsunderlag för att beskriva krav på en applikation som ska upphandlas. I ett senare skede kan applikationen konkretiseras i en fysisk applikation. Fysiska applikationer kan beskrivas på olika nivåer. Den mest generella nivån är att identifiera den konkreta applikationen med sitt namn som leverantören gett den eller ett namn som används inom verksamheten. Vidare är det möjligt att lägga till version för att på så sätt kunna beskriva hur applikationen ska utvecklas och få in den i planer. Till sist är det också möjligt att definiera element för var applikationen är installerad, dvs instanser. Dessa instanser kan man normalt sett hitta genom inventeringsverktyg, dvs applikationer som faktiskt exekverar eller är installerade. I praktiken framgår det ofta av namnsättningen på applikation om det är en logisk (konceptuell) eller fysisk applikation som avses (exvis. Ordbehandlare eller Word). En rekommendation är därför att inte lägga för mycket kraft på att definiera om en applikation är logisk eller fysisk. Det viktiga är att visa vad en applikation består av och hur den förhåller sig till andra applikationer. För att visa hur en applikation bryts ner från logisk till fysisk, ner till instansnivå används relationen ´del av´. Se applikationstjänster och applikationsgränssnitt för vägledning beskrivning av hur applikationer interagerar med varandra. | Archimate: Application Component: An encapsulation of application functionality aligned to implementation structure, which is modular and replaceable. It encapsulates its behavior and data, exposes services, and makes them available through interfaces. TOGAF: Logical Application Component: An encapsulation of application functionality that is independent of a particular implementation. For example, the classification of all purchase request processing applications implemented in an enterprise. Physical Application Component: An application, application module, application service, or other deployable component of functionality. For example, a configured and deployed instance of a Commercial Off-The-Shelf (COTS) Enterprise Resource Planning (ERP) supply chain management application. UAF: ResourceArtifact: A type of man-made object that contains no human beings (i.e., satellite, radio, petrol, gasoline, etc.). ResourcePerformer: An abstract grouping of elements that can perform Functions. ActualResourceRole: An instance of a ResourcePerformer. ResourceRole: Usage of a ResourcePerformer in the context of another ResourcePerformer. Creates a whole-part relationship. Software: A sub-type of ResourceArtifact that specifies an executable computer program. |
automatiserat beteende som utförs internt i en applikation | Deklarationsmottagning Ärenderegistrering Ärendekvittens Ärendedistribution Ärendesökning | Applikationsfunktioner beskriver applikationens interna beteende på en abstrakt nivå. I den mån applikationens beteende exponeras utåt görs det via applikationstjänster. Det råder ett många-till-många-förhållande mellan applikationsfunktion och applikationstjänst. Endast det nödvändiga beteendet anges (typiskt de funktioner som behövs för att göra en applikationstjänst begriplig). Applikationsfunktionen ska anges på abstraktionsnivå som passar det aktuella sammanhanget. Applikationsfunktioner kan användas i sekvensdiagram för att beskriva applikationens interna funktion. | Archimate: Application function: An application function represents automated behavior that can be performed by an application component. UAF: Function: An Activity which is specified in the context to the ResourcePerformer (human or machine) that IsCapableToPerform it. | |
Definitionen motsvarar termerna: informationstjänst informationssystemtjänst digital tjänst | mekanism för att möjliggöra tillgång till en eller flera applikationsfunktioner genom ett bestämt gränssnitt som följer en tjänstebeskrivning | Arbetsgivardeklaration Nationell Patientöversikt Ärendehantering | Applikationstjänster levereras och konsumeras med hjälp av informationsteknologi. De kan ha olika typer av gränssnitt som riktar sig till både människor och tekniska system, exempelvis e-tjänster eller API:er. Tjänster bör namnsättas olika beroende på vad de har för huvudsaklig funktion. De vanligaste varianterna är att namnet ges efter 1) den process eller verksamhetsfunktion tjänsten stödjer, 2) den information tjänsten tillhandahåller, eller 3) den generella, återanvändbara funktion tjänsten tillhandahåller. Applikationstjänster kan ha samma namn som verksamhetstjänster, men representerar då den tekniska implementationen av dessa. Det kan också vara så att flera applikationstjänster behövs för att realisera en verksamhetstjänst och en applikationstjänst kan vara del i realiseringen av flera verksamhetstjänster. Applikationstjänster realiseras av applikationer och dessas funktioner. Arkitekturen kan beskriva applikationerna som svarta lådor, dvs utan interna funktioner. I detta fall kopplas tjänsterna direkt till applikationerna. Det är också möjligt att koppla tjänsterna till applikationer via funktioner. Detta görs om det finns behov av att beskriva vilken funktion som realiserar vilken tjänst och om arkitekten vill bryta ner applikationen i funktioner. Både producenter och konsumenter av tjänster realiserar dessa. Om tjänsten har producent- eller konsumentspecifika gränssnitt modelleras dessa separat och kopplas därefter till producerande respektive konsumerande applikation. Detaljer om applikationstjänster kan beskrivas med hjälp av elementen som är definierade i sektionen tjänsteutökning nedan. Exempelvis kan gränssnitt, tjänstefunktion och det datainnehåll som utbyts med tjänsten beskrivas. Dessa detaljer kallas sammanslaget för tjänstebeskrivning och vägleder utformandet av tekniska tjänstekontrakt eller API:er som kan tolkas av IT systemen. | Archimate: Application Service: An application service represents an explicitly defined exposed application behavior. TOGAF: Information System Service: The automated elements of a business service. An information system service may deliver or support part or all of one or more business services. UAF: ServiceSpecification: The specification of a set of functionality provided by one element for the use of others. ActualService: An instance of a ServiceSpecification. VLDS: Tjänst: Mekanism för att möjliggöra tillgång till en eller flera funktioner genom ett bestämt gränssnitt där implementationen överensstämmer med de riktlinjer som är specificerade i tjänstebeskrivningen. OASIS SOA Reference Model: Service: A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description. |
accesspunkt och beskrivning av sätt att interagera med en applikationstjänst | Deklarationshanterare Remissproducent Engagemangsindex Elevregisterproducent Ärendedistributör Arkivfrågehanterare | Ett applikationsgränssnitt kan representera och beskriva accesspunkter, protokoll, kommandon, operationer och datainnehåll som utbyts mellan applikationer som producerar och konsumerar tjänster. En applikationstjänst kan innehålla flera olika gränssnitt för olika teknologier, interaktionsmönster eller delar av tjänsten. Exempelvis kan det finnas ett gränssnitt för att administrera innehåll och ett annat för att konsumera. Gränssnitt namnges med fördel med en kombination av ämnet eller informationsmängden (Exvis Ärende) som gränssnittet hanterar och rollen det har i processen (Exvis Distributör). | Archimate: Application Interface: A point of access where application services are made available to a user, another application component, or a node. UAF: ServiceInterface: A contract that defines the ServiceMethods and ServiceMessageHandlers that the ServiceSpecification realizes. SOA RM: Service Interface: The service interface is the means for interacting with a service. It includes the specific protocols, commands, and information exchange by which actions are initiated that result in the real world | |
Teknikrelaterade element | ||||
Definitionen motsvarar termerna: teknisk komponent (TOGAF: Technology Component) teknikkomponent infrastrukturkomponent | logisk eller fysisk resurs som manipulerar, interagerar med eller innehåller andra logiska eller fysiska resurser | Logiska:
Fysiska:
| Noder är aktiva element som exekverar and bearbetar artefakter vilka i sig är representationen av komponenter och dataobjekt. Noder används exempelvis för att modellera applikationsservrar, databasservrar eller klienter. En nod är ofta en kombination av en eller flera maskinvaror och systemprogramvaror som ger en komplett miljö för exekvering. En nod kan bestå av andra noder. Man kan använda ett attribut för att skilja på logisk och fysisk nod/teknikkomponent. Det är möjligt att modellera olika versioner av noder, exempelvis MS SQL Server 2012 och 2017. I sådant fall rekommenderas att modellera dessa som två olika element. Detta gör det möjligt att beskriva utveckling över tid. Noder realiseras av utrustning och systemprogramvara och de realiserar teknikfunktioner, tekniska gränssnitt och tekniska tjänster. De använder sig av kommunikationsvägar som är kopplade mot nätverk. | |
specialisering av nod som representerar en fysisk resurs vilken har kapacitet att göra beräkningar |
| Utrustning används för att modellera maskinvara såsom stordatorer, PC, nätverkskomponenter med mera. En utrustning är ofta del av en nod tillsammans med en eller flera programvaror. En utrustning kan bestå av andra utrustningar. Utrustning har ofta relationer till kommunikationsnätverk och använder dessa. Utrustning realiserar noder. Systemprogramvara knyts i regel till utrustning eftersom den exekveras på en utrustning. | ||
programvara som tillgängliggör eller bidrar till en miljö för lagring, beräkning och användning av programvaran eller av den data som programvaran hanterar | Operativsystem | Systemprogramvara är en specialisering av en nod som används för att modellera den programvarumiljö som applikationer exekverar i. Ofta kombineras systemprogramvara med en utrustning för att formera en komplett nod. Systemprogramvara kan knytas till annan systemprogramvara för att beskriva lager av programvara som exekverar ovanpå varandra. Systemprogramvara använder kommunikationsnätverk. De används av utrustning och realiserar noder. | ||
struktur som innehåller utrustningar och skapar kommunikationsvägar | Nätverk och subnät | Ett kommunikationsnätverk knyter samman två eller flera utrustningar och möjliggör dirigering och överföring av data inklusive databaserad kommunikation för exempelvis video och röstöverföring. I sin enklaste form är det en länk mellan två utrustningar men det kan bestå av multipla länkar och associerad nätverksutrustning. Kommunikationsnätverk realiserar en eller flera kommunikationsvägar. Det representerar den fysiska realiseringen av den logiska länken mellan två noder. De används av systemprogramvara. Kommunikationsnätverk har egenskaper som exempelvis bandbredd och fördröjning, Ett kommunikationsnätverk kan bestå av subnät. Det kan aggregera enheter och systemprogramvara för att exempelvis modellera routrar, switchar och brandväggar som en del av nätverksinfrastrukturen. | ||
länk som möjliggör informationsutväxling mellan två eller flera noder | Länk mellan två noder. | I mindre avancerade fall modelleras en kommunikationsväg med hjälp av en relation mellan noder som beskriver hur noderna använder sig av varandra. Om behov finns att göra mera avancerad modeller kan elementtypen kommunikationsväg användas. Exempelvis om det är fler än två noder som använder samma kommunikationsväg. En kommunikationsväg binder samman två eller flera noder. Elementet används för att modellera den logiska kommunikationen och relationen mellan noder. Den realiseras av ett eller flera kommunikationsnätverk vilka representerar de fysiska kommunikationslänkarna. En kommunikationsväg kan aggregera noder. Egenskaper, som exempelvis bandbredd och fördröjning, är vanligtvis aggregerade från underliggande nätverk. | ||
teknisk tjänst | teknisk mekanism för att möjliggöra tillgång till en eller flera noder genom ett bestämt gränssnitt |
| En distinkt (funktionell) tjänst som erbjuds via ett eller flera tekniskt gränssnitt. En teknisk tjänst uppvisar funktionaliteten hos en nod. En nod exponerar en teknisk tjänst genom att knyta tekniska gränssnitt till sig. En teknisk tjänst kan bestå av andra tekniska tjänster. En teknisk tjänst realiseras av en nod och/eller en teknikfunktion samt har tekniskt gränssnitt. | |
tekniska beteenden hos en nod |
| En teknikfunktion beskriver en nods interna beteende. För användaren av en teknikfunktion är detta beteende osynligt. Om dess beteende exponeras externt sker detta alltid genom en eller flera tekniska tjänster. Funktionen kan vara på valfri nivå utifrån det sammanhang som den förekommer i. En teknikfunktion kan realisera en teknisk tjänst.Tekniska tjänster som hör till en viss teknikfunktion kan användas av andra teknikfunktioner. En nod kan kopplas till en teknikfunktion vilket innebär att noden realiserar och utför teknikfunktionen. | ||
tekniskt gränssnitt | representerar en åtkomstpunkt för en teknisk tjänst som erbjuds av en nod | Typer av interface/protokoll:
instanser: | Det tekniska gränssnittet exponerar en teknisk tjänst för sin omgivning. Samma tjänst kan uppvisas genom andra tekniska gränssnitt. Ett teknisk gränssnitt kan vara del av en nod vilket innebär att gränssnittet realiseras och erbjuds av noden och kan nyttjas av andra noder. Det tekniska gränssnittet specificerar hur andra noder kan få åtkomst till en nods teknisk tjänst. |
Relationer inom lagret
Källelement | Relation | Målelement | Källa |
|---|---|---|---|
applikationstjänst | del av | applikationstjänst | Archimate (aggregates/composed of) |
applikationstjänst | beror av | applikationstjänst | Archimate (aggregates/composed of) |
applikationstjänst | har | applikationsgränssnitt | Archimate (composition) |
applikationstjänst | realiserar | applikationsfunktion | Archimate (realization) |
applikationstjänst | realiseras av | applikation | Archimate (serves) |
applikationsgränssnitt | tillhör | applikationstjänst | Archimate (assigned to) |
applikationsgränssnitt | realiseras av | applikation | Archimate (serves) |
applikationsfunktion | del av | applikationsfunktion | Archimate (aggregates/composed of) |
applikationsfunktion | realiseras av | applikation | Archimate (serves) |
applikation | del av | applikation | Archimate (aggregates/composed of) |
applikation | realiserar | applikationstjänst | Archimate (realizes) |
applikation | realiserar | applikationsfunktion | Archimate (realizes) |
applikation | realiserar | applikationsgränssnitt | Archimate (realizes) |
applikation | exekverar på | nod | Archimate (realises, serves) |
nod | exekverar | applikation | Archimate (realises, serves) |
nod | del av | nod | Archimate (aggregates/composed of) |
nod | realiserar | teknikfunktion | Archimate (realizes) |
nod | realiserar | teknisk tjänst | Archimate (realizes) |
nod | realiserar | tekniskt gränssnitt | Archimate (realizes) |
nod | använder | kommunikationsväg | Archimate (flow) |
nod | realiseras av | systemprogramvara | Archimate (serves) |
nod | realiseras av | utrustning | Archimate (serves) |
teknikfunktion | realiseras av | nod | Archimate (serves) |
teknikfunktion | del av | teknikfunktion | Archimate (aggregates/composed of) |
teknikfunktion | realiserar | teknisk tjänst | Archimate (realizes) |
teknisk tjänst | realiseras av | teknikfunktion | Archimate (serves) |
teknisk tjänst | del av | teknisk tjänst | Archimate (aggregates/composed of) |
teknisk tjänst | beror av | teknisk tjänst | Archimate (triggers) |
teknisk tjänst | realiseras av | nod | Archimate (serves) |
teknisk tjänst | har | tekniskt gränssnitt | Archimate (assigned to) |
tekniskt gränssnitt | tillhör | teknisk tjänst | Archimate (serves) |
tekniskt gränssnitt | realiseras av | nod | Archimate (serves) |
kommunikationsväg | del av | kommunikationsväg | Archimate (aggregates/composed of) |
kommunikationsväg | används av | nod | Archimate (flow) |
kommunikationsväg | realiseras av | kommunikationsnätverk | Archimate (serves) |
kommunikationsnätverk | realiserar | kommunikationsväg | Archimate (realizes) |
kommunikationsnätverk | del av | kommunikationsnätverk | Archimate (aggregates/composed of) |
kommunikationsnätverk | används av | systemprogramvara | Archimate (triggers) |
kommunikationsnätverk | används av | utrustning | Archimate (triggers) |
utrustning | använder | kommunikationsnätverk | Archimate (triggers) |
utrustning | del av | utrustning | Archimate (aggregates/composed of) |
utrustning | används av | systemprogramvara | Archimate (triggers) |
utrustning | realiserar | nod | Archimate (realizes) |
systemprogramvara | realiserar | nod | Archimate (Realizes) |
systemprogramvara | del av | systemprogramvara | Archimate (aggregates/composed of) |
systemprogramvara | används av | utrustning | Archimate (triggers) |
systemprogramvara | använder | kommunikationsnätverk | Archimate (triggers) |
Relationer till andra lager
Källelement | Relation | Målelement | Källa |
|---|---|---|---|
applikation | möjliggör | förmåga | Archimate (Association) |
förmåga | möjliggörs av | applikation | Archimate (Association) |
applikation | använder | datalager | TOGAF (Logical Application Component uses Logical Data Component) |
datalager | används av | applikation | TOGAF (Logical Data Component Used By Logical Application Component) |
applikation | använder | dataentitet | Archimate (Access, Association) |
dataentitet | används av | applikation | Archimate (Access, Association) |
applikationstjänst | använder | dataentitet | TOGAF (Information System Service Uses Data Entity) Archimate (Access, Association) |
dataentitet | används av | applikationstjänst | TOGAF (Data Entity Used By Information System Service) Archimate (Access, Association) |
applikationstjänst | automatiserar | verksamhetstjänst | TOGAF (Information System Service Automates some or all of Business Service) Archimate (Serve, Trigger, Flow, Association) |
verksamhetstjänst | automatiseras av | applikationstjänst | TOGAF (Information System Service Automates some or all of Business Service) Archimate (Serve, Trigger, Flow, Association) |
applikationstjänst | stödjer | process | Archimate (Serve, Trigger, Flow, Association) |
process | stöds av | applikationstjänst | Archimate (Serve, Trigger, Flow, Association) |
applikationstjänst | möjliggör | förmåga | Archimate (Association) |
förmåga | möjliggörs av | applikationstjänst | Archimate (Association) |
nod | möjliggör | förmåga | Archimate (Association) |
förmåga | möjliggörs av | nod | Archimate (Association) |
teknisk tjänst | möjliggör | förmåga | Archimate (Association) |
förmåga | möjliggörs av | teknisk tjänst | Archimate (Association) |
plats | innehåller | nod | Archimate (Composition) |
nod | finns på | plats | Archimate (Association) |
Koppling till Archimate
Bifogat finns en excelmatris som beskriver alla relationer som är tillåtna enligt Archimate standarden och hur dessa mappar till TOGAF. Det ingår även kommentarer som visar vilka vi valt att inkludera i ramverket.
Förslag till vidareutveckling
Här dokumenteras förslag till kommande versioner av metamodellen.
Service extension som beskriver hur man modellerar metoder, funktioner, meddelanden etc för tjänster. Utgående från Vägledning för Digital Samverkan, OASIS SOA Reference Model etc.
Metamodellen beskriver endast statiska samband, inte dynamiska. Utökar man metamodellen med dynamiska relationer, exempelvis "använder", "anropar" och liknande kan den användas för att beskriva dynamiska samband, förslagsvis i form av sekvensdiagram och aktivitetsdiagram. Dessa dynamiska relationstyper skulle även kunna användas i statiska diagram för att översiktligt beskriva att en applikation använder en annan applikation.
Arbetsmaterial
OBS! Material under denna rubrik granskas ej och kommer ej publiceras på publika siten. Är dock relevant för spårbarhet i arbetet och eventuell vidareutveckling.
Inventering av standarder och referenser
UAF
Unified Architecture Framework publiceras av OMG. Senaste version en är 1.0 från December 2017:
UAF har inget specifikt tekniskt lager som TOGAF eller Archimate. Det lager som innehåller mest tekniska element är Resurs-lagret.
UAF har en ganska komplex metamodell, här följer de element som bedömts mest relevanta i detta sammanhang:
CapabilityConfiguration: A composite structure representing the physical and human resources (and their interactions) in an enterprise, assembled to
meet a capability.
ResourceArtifact: A type of man-made object that contains no human beings (i.e., satellite, radio, petrol, gasoline, etc.).
ResourcePerformer: An abstract grouping of elements that can perform Functions.
Software: A sub-type of ResourceArtifact that specifies an executable computer program.
ResourceRole: Usage of a ResourcePerformer in the context of another ResourcePerformer. Creates a whole-part relationship.
ActualResourceRole: An instance of a ResourcePerformer.
ResourceConnector: A channel for exchange between two ResourceRoles.
ResourceExchange: Asserts that a flow can exist between ResourcePerformers (i.e., flows of data, people, materiel, or energy).
ResourceExchangeItem: An abstract grouping for elements that defines the types of elements that can be exchanged between ResourcePerformers and conveyed by a ResourceExchange.
ResourcePort: An interaction point for a ResourcePerformer through which it can interact with the outside environment and which is defined by a ResourceInterface.
ResourceInterface: A declaration that specifies a contract between the ResourcePerformers it is related to and any other ResourcePerformers it can interact with. It is also intended to be an implementation of a specification of an Interface in the Business and/or Service layer.
Function: An Activity which is specified in the context to the ResourcePerformer (human or machine) that IsCapableToPerform it.
ServiceSpecification: The specification of a set of functionality provided by one element for the use of others.
ServiceConnector: A channel for exchange between two ServiceSpecifications. Where one acts as the consumer of the other.
ServiceMethod: A behavioral feature of a ServiceSpecification whose behavior is specified in a ServiceFunction.
ServiceInterface: A contract that defines the ServiceMethods and ServiceMessageHandlers that the ServiceSpecification realizes.
ServiceFunction: An Activity that describes the abstract behavior of ServiceSpecifications, regardless of the actual implementation.
ActualService: An instance of a ServiceSpecification.
TOGAF
TOGAF är en standard som utvecklas och förvaltas av medlemmar i The Open Group Architecture Forum. Den första versionen kom 1995 och baserades på Technicahl Architecture Framework for Information Management (TAFIM) som i sin tur utvecklats av US Department of Defense (DoD). Aktuell version är 9.2.
Den del av TOGAF som är av specifikt intresse är Part IV - Architecture Content Framework. Syftet med detta avsnitt är att ge en kort introduktion till detta ramverk. Värt att notera redan från början är att ramverket handlar om vad man modellerar men inte exakt hur.
Ramverket använder tre kategorier för att beskriva typen av produkt som är resultatet av ett arkitekturarbete:
En arkitekturleverabel (Architecture Deliverable) är en arbetsprodukt som är avtalsmässigt specificerad och i sin tur formellt granskad, överenskommen och undertecknad av intressenterna.
En artefakt (Artifact) är en arkitektonisk arbetsprodukt som beskriver en aspekt av ett byggblock i arkitekturen. En artefakter kan vara
Listor (Catalogs) av saker. Tabeller helt enkelt.
Matriser (Matrices) för att visa på samband mellan saker.
Diagram (Diagrams) används för att visualisera saker och samband mellan saker. Bilder helt enkelt.
Ett byggblock (Building Block) representerar en (potentiellt återanvändbar) komponent av som kan kombineras med andra byggblock för att leverera arkitekturer och lösningar. Dessa finns i två "smaker": ABB (Architectural building block) som beskriver en förmåga medan SBB (Solution building block) beskriver komponenter som implementerar förmågor.
Föga förvånande finns verktyg, t.ex. Sparx EA, som är bra på att generera artefakter, dvs utifrån ett diagram skapa tillhörande listor, matriser och beskrivande text.
Vidare innehåller TOGAF en metamodell för innehåll (kap 30). Denna metamodell beskriver vilka typer av arkitektoniska byggblock (ABB) som man kan/bör använda för att beskriva olika aspekter av arkitekturen. Metamodellen innehåller även relationer mellan de olika typerna av ABB.
Figuren ovan visar de olika områden som finns, grupperat efter faserna i arkitekturutvecklingsmetoden TOGAF Achitecture Development Method (ADM)
Figuren ovan visar de typer ABB som TOGAF tänker sig att man kan använda vid beskrivning av en arkitekturen bakom affärstjänst jämte inbördes relationer. Det som definitivt är relevant för metamodellen för teknisk arkitektur är entiteterna inom applikation och teknik ovan. Notera att de ABB som är vita ingår i kärnmodellen medan lila, gröna och röda är olika utökningar. Tabellen nedan innehåller en kortbeskrivning av respektive entitet.
Entitet | Beskrivning |
|---|---|
Data Entity | An encapsulation of data that is recognized by a business domain expert as a thing. Logical data entities can be tied to applications, repositories, and services and may be structured according to implementation considerations. |
Logical Data Component | A boundary zone that encapsulates related data entities to form a logical location to be held; for example, external procurement information. |
Physical Data Component | A boundary zone that encapsulates related data entities to form a physical location to be held. For example, a purchase order business object, comprising purchase order header and item business object nodes. |
Information System Service | The automated elements of a business service. An information system service may deliver or support part or all of one or more business services. |
Logical Application Component | An encapsulation of application functionality that is independent of a particular implementation. For example, the classification of all purchase request processing applications implemented in an enterprise. |
Physical Application Component | An application, application module, application service, or other deployable component of functionality. For example, a configured and deployed instance of a Commercial Off-The-Shelf (COTS) Enterprise Resource Planning (ERP) supply chain management application. |
Technology Service | A technical capability required to provide enabling infrastructure that supports the delivery of applications. |
Logical Technology Component | An encapsulation of technology infrastructure that is independent of a particular product. A class of technology product; for example, supply chain management software as part of an Enterprise Resource Planning (ERP) suite, or a Commercial Off-The-Shelf (COTS) purchase request processing enterprise service. |
Physical Technology Component | A specific technology infrastructure product or technology infrastructure product instance. For example, a particular product version of a Commercial Off-The-Shelf (COTS) solution, or a specific brand and version of server. |
Eftersom vi nu vet vilka typer av byggblock vi ska beskriva kan man ju fundera över vilka artefakter som är lämpliga. TOGAF innehåller tanker om detta också (kap 31).
Bilden ovan innehåller förslag på artefakter ingående i kärnmodellen. En fullständig beskrivning av respektive artefakt finns här. (Att göra: skapa tabell)
Slutligen: TOGAF definierar inte själv metamodeller för diagram. Däremot finner man enkelt förslag på hur man göra det på olika webbplatser. Ett exempel är togaf-modelling.org.
Archimate
ArchiMate EA är ett modelleringsspråk (se ArchiMate® 3.0.1 Specification, an Open Group Standard), ett visuellt språk, med en uppsättning av default ikonografi för att beskriva, analysera och kommunicera många aspekter av Enterprise Architecture när de förändras över tid. Det är en standard bestående av en uppsättning av entiteter och relationer med tillhörande ikonografi för representation i bl a arkitekturbeskrivningar. Det är en teknisk standard från The Open Group baserad på koncept i ISO/IEC/IEEE 42010:2011 (tidigare IEEE 1471).
ArchiMate EA inkluderar concept för att specificera närrelaterade arkitekturer, specifika vypunkter för olika intressenter och en mekanism för modelleringsspråklig anpassning. Det ger vidare ett integrerat arkitekturellt angreppssätt som beskriver och visualiserar olika arkitekturdomäner och deras underliggande relationer och beroenden. Det skiljer även mellan modellelement och notation för att tillåta en varierad intressentorienterad beskrivning av arkitekturen. Det använder serviceorientering för att skilja och relatera EA-lagren Verksamhet (Business), Applikation (Application) och Infrastruktur (Technology).
(kap. 3.5 i ArchiMate 3.0.1 Specifikation)
Mappning mellan termer i ArchiMate och i TOGAF finns på "Mapping terms in the two standards". Exempel på modelltyper som visar hur ArchiMate kan användas finns på "ArchiMate Example Views".
De EA-lager som är relevanta i den här metamodellen är Applikation (Application) och Infrastruktur (Technology & Physical).
Applikation (Application)
(kap. 9.1 i ArchiMate 3.0.1 Specifikation)
Figuren visar inte alla tillåtna relationer. Alla element i modelleringsspråket kan ha relationerna "composition", "aggregation" och "specialization" med element av samma typ. EA-lagret används typiskt till att modellera arkitektur för informationssystem och inkluderar applikationsarkitektur, definierad enligt TOGAF, som beskriver applikationens (systemets) struktur och interaktion.
Entitet | Beskrivning |
|---|---|
Active Structure Elements | |
Application Component | An application component represents an encapsulation of application functionality aligned to implementation structure, which is modular and replaceable. It encapsulates its behavior and data, exposes services, and makes them available through interfaces. It may be assigned to one or more application functions. An application component has one or more application interfaces, which expose its functionality. Application interfaces of other application components may serve an application component. The element is used to model entire applications (i.e. deployed and operational IT systems as defined by the TOGAF framework) and individual parts of such applications, at all relevant levels of detail. The name of an application component should preferably be a noun. |
Application Collaboration | An application collaboration represents an aggregate of two or more application components that work together to perform collective application behavior. It typically models a logical or temporary collaboration of application components, and does not exist as a separate entity in the enterprise. It is an active structure element that may be assigned to one or more application interactions or other application internal behavior elements, which model the associated behavior. The name of an application collaboration should preferably be a noun. |
Application Interface | An application interface represents a point of access where application services are made available to a user, another application component, or a node. It specifies how the functionality of a component can be accessed by other elements through a kind of contract that a component exposing this interface must fulfill. This may include parameters, protocols used, pre- and post-conditions, and data formats. An application interface exposes application services to the environment. The same application service may be exposed through different interfaces, and the same interface may expose multiple services. It may be part of an application component through composition. The name of an application interface should preferably be a noun. |
Behavior Elements | |
Application Function | An application function represents automated behavior that can be performed by an application component. It describes the internal behavior of an application component. If this behavior is exposed externally, this is done through one or more services. An application function abstracts from the way it is implemented. Only the necessary behavior is specified. An application function may realize one or more application services. Application services of other application functions and technology services may serve an application function. An application function may access data objects. An application component may be assigned to an application function (which means that the application component performs the application function). The name of an application function should preferably be a verb ending with “ing”. |
Application Interaction | An application interaction represents a unit of collective application behavior performed by (a collaboration of) two or more application components. It describes the collective behavior that is performed by the components that participate in an application collaboration. It can also specify the externally visible behavior needed to realize an application service. An application collaboration may be assigned to an application interaction. An application interaction may realize an application service. Application services and technology services may serve an application interaction. An application interaction may access data objects. The name of an application interaction should clearly identify a series of application behaviors; e.g., “Client profile creation”. |
Application Process | An application process represents a sequence of application behaviors that achieves a specific outcome. It describes the internal behavior performed by an application component that is required to realize a set of services. An application process may realize application services. Other application services may serve (be used by) an application process. An application process may access data objects. An application component may be assigned to an application process (which means that this component performs the process). The name of an application process should clearly identify a series of application behaviors; e.g., “Claims adjudication process”. |
Application Event | An application event is an application behavior element that denotes a state change. Application functions and other application behavior may be triggered or interrupted by an application event. Also, application behavior may raise events that trigger other application behavior. Unlike processes, functions, and interactions, an event is instantaneous; it does not have duration. An application event may trigger or be triggered (raised) by an application function, process, or interaction. An application event may access a data object and may be composed of other application events. The name of an application event should preferably be a verb in the perfect tense; e.g., “claim received”. |
Application Service | An application service represents an explicitly defined exposed application behavior. It exposes the functionality of components to their environment. This functionality is accessed through one or more application interfaces. It may require, use, and produce data objects. An application service should be meaningful from the point of view of the environment; it should provide a unit of behavior that is, in itself, useful to its users. It may serve business processes, business functions, business interactions, or application functions. An application function may realize an application service. An application interface may be assigned to an application service. An application service may access data objects. The name of an application service should preferably be a verb ending with “ing”. |
Passive Structure Elements | |
Data Object | A data object represents data structured for automated processing. It should be a self-contained piece of information with a clear meaning to the business, not just to the application level. A data object typically models an object type (cf. a UML class) of which multiple instances may exist in operational applications. An important exception is when a data object is used to model a data collection such as a database, of which only one instance exists. The name of a data object should preferably be a noun. |
Infrastruktur (Technology & Physical)
(kap. 10.1 i ArchiMate 3.0.1 Specifikation)
Entitet | Beskrivning |
|---|---|
Active Structure Elements | |
Node | A computational or physical resource that hosts, manipulates, or interacts with other computational or physical resources. A collection of technology components of hardware and software that provide the services used to support applications. |
Device | A device is a specialization of a node that represents a physical IT resource with processing capability. It is typically used to model hardware systems such as mainframes, PCs, or routers. |
System Software | Software that provides or contributes to an environment for storing, executing, and using software or data deployed within it. |
Communication Network | A communication network can consist of sub-networks. It can aggregate devices and system software, for example, to model the routers, switches, and firewalls that are part of the network infrastructure. |
Path | A path connects two or more nodes. A path is realized by one or more networks. A path can aggregate nodes. |
Technology Interface | A technology interface represents a point of access where technology services offered by a node can be accessed. |
Technology Colaboration | A technology collaboration represents an aggregate of two or more nodes that work together to perform collective technology behavior. |
Behavior Elements | |
Technology Service | A technology service exposes the functionality of a node to its environment. This functionality is accessed through one or more technology interfaces. |
Technology Function | A technology function represents a collection of technology behavior that can be performed by a node. |
Technology Process | A technology process represents a sequence of technology behaviors that achieves a specific outcome. |
Technology Interaction | A technology interaction represents a unit of collective technology behavior performed by (a collaboration of) two or more nodes. |
Technology Event | A technology event is a technology behavior element that denotes a state change. |
Passive Structure Elements | |
Artifact | An artifact represents a tangible element in the IT world. Artifact is a specialization of technology object. It is typically used to model (software) products such as source files, executables, scripts, database tables, messages, documents, specifications, and model files. An instance (copy) of an artifact can be deployed on a node. An artifact could be used to represent a physical data component that realizes a data object. The name of an artifact should preferably be the name of the file it represents; e.g., “order.jar”. An artifact may consist of sub-artifacts. |
OASIS SOA Reference Model
Service
A service is a mechanism to enable access to one or more capabilities, where the access is
provided using a prescribed interface and is exercised consistent with constraints and policies as
specified by the service description. A service is provided by an entity – the service provider –
for use by others, but the eventual consumers of the service may not be known to the service
provider and may demonstrate uses of the service beyond the scope originally conceived by the
provider.
A service is accessed by means of a service interface, where the interface
comprises the specifics of how to access the underlying capabilities. There are no constraints on
what constitutes the underlying capability or how access is implemented by the service provider.
Thus, the service could carry out its described functionality through one or more automated
and/or manual processes that themselves could invoke other available services.
A service is opaque in that its implementation is typically hidden from the service consumer
except for (1) the information and behavior models exposed through the service interface and (2)
the information required by service consumers to determine whether a given service is
appropriate for their needs
Service Interface
The service interface is the means for interacting with a service. It includes the specific protocols,
commands, and information exchange by which actions are initiated that result in the real world
effects as specified through the service functionality portion of the service description.
Information Model
The information model of a service is a characterization of the information that may be exchanged
with the service. Only information and data that are potentially exchanged with a service are
generally included within that service's information model.
The scope of the information model includes the format of information that is exchanged, the
structural relationships within the exchanged information and also the definition of terms used.
Service Description
One of the hallmarks of a Service Oriented Architecture is the large amount of associated
documentation and description. The service description represents the information needed in order to use a service. In most
cases, there is no one “right” description but rather the elements of description required depend
on the context and the needs of the parties using the associated entity. While there are certain
elements that are likely to be part of any service description, most notably the information model,
many elements such as function and policy may vary.
The purpose of description is to facilitate interaction and visibility, particularly when the
participants are in different ownership domains, between participants in service interactions. By
providing descriptions, it makes it possible for potential participants to construct systems that use
services and even offer compatible services.
Service policy
Conceptually, there are three aspects of policies: the policy assertion, the policy owner
(sometimes referred to as the policy subject) and policy enforcement.
For example, the assertion: “All messages are encrypted” is an assertion regarding the forms of
messages. As an assertion, it is measurable: it may be true or false depending on whether the
traffic is encrypted or not. Policy assertions are often about the way the service is realized; i.e.,
they are about the relationship between the service and its execution context, see 3.3.3.
A policy always represents a participant’s point of view. An assertion becomes the policy of a
participant when they adopt the assertion as their policy. This linking is normally not part of the
assertion itself. For example, if the service consumer declares that “All messages are encrypted”,
then that reflects the policy of the service consumer. This policy is one that may be asserted by
the service consumer independently of any agreement from the service provider.
Finally, a policy may be enforced. Techniques for the enforcement of policies depend on the
nature of the policy. Conceptually, service policy enforcement amounts to ensuring that the policy
assertion is consistent with the real world. This might mean preventing unauthorized actions to be
performed or states to be entered into; it can also mean initiating compensatory actions when a
policy violation has been detected. An unenforceable constraint is not a policy; it would be better
described as a wish.
Service Contract
Whereas a policy is associated with the point of view of individual participants, a contract
represents an agreement between two or more participants. Like policies, contracts can cover a
wide range of aspects of services: quality of service agreements, interface and choreography
agreements and commercial agreements. Note that we are not necessarily referring to legal
contracts here.
Thus, following the discussion above, a service contract is a measurable assertion that governs
the requirements and expectations of two or more parties. Unlike policy enforcement, which is
usually the responsibility of the policy owner, contract enforcement may involve resolving
disputes between the parties to the contract. The resolution of such disputes may involve appeals
to higher authorities.
Vägledning för Digital Samverkan
Informationsutbyte inom digital samverkan ska baseras på tjänster. Tjänsterna blir därmed en central del av arkitekturen, en s k tjänsteorienterad arkitektur. Detta innebär i stort att fokus läggs på att beskriva det som sker mellan aktörer snarare än det som sker internt hos aktörerna. Det omfattar både vad aktörerna gör (processer), vilken information som utbyts och hur utbytet sker med hjälp av digitala tjänster. Digitala tjänster är ett samlingsnamn för både e-tjänster (mellan människa och system) och bastjänster (mellan tekniska system).
Figur 13 nedan visar hur samverkande aktörer utifrån processer och deras informationsbehov kan identifiera behovet av olika tjänster av olika slag. Modellen visar en typisk e-tjänst (T1) som används av en kund för att samverka med en aktör. Denna använder i sin tur bastjänster (T2 och T3) för att samverka med ytterligare aktörer. Notera att samma tjänst, som i fallet T1 och T2, kan stödja flera interaktioner mellan olika aktörer.
Det är givetvis av stor vikt att samtliga tjänster uppfyller ställda krav på informationssäkerhet samt integritets- och andra rättsliga aspekter. För att detta ska vara möjligt bör ansvar för dessa aspekter över tjänstens hela livscykel pekas ut redan tidigt i processen.
Figur 13. Tjänster (T1, T2 & T3) kopplade till process och information.
1.1.1.1 Tjänstebeskrivning
Tjänster beskrivs och publiceras i en tjänstekatalog. En komplett tjänstebeskrivning beskriver tjänstens profil och gränssnitt, samt beskrivningar av samtliga instanser av tjänsten. En instans motsvaras av en specifik implementation av tjänsten, t ex en tjänst hos en specifik kommun.
Figur 14. Tjänstebeskrivningens delar.
Profil
Profildelen av tjänstebeskrivningen innehåller en övergripande beskrivning av tjänsten och dess sammanhang. Detta omfattar saker som namn och textuell beskrivning av tjänsten men även vilka krav tjänsten uppfyller, vilka begrepp som används i tjänsten mm.Logiskt gränssnitt
Det logiska gränssnittet innehåller en beskrivning av samtliga gränsytor som producenten och konsumenten av tjänsten ska implementera. Här finns i huvudsak beskrivningar av anrop, meddelanden och sekvenser som ska tas hänsyn till vid implementation av tjänsten. Notera att denna del av beskrivningen är logisk, dvs utan koppling till specifik teknik.Tekniskt gränssnitt
Här beskrivs tjänstens samtliga tekniska gränssnitt. En tjänst kan ha flera olika tekniska gränssnitt vilka kan utformas för olika kanaler som exempelvis smartphone/app, webbläsare, xml-data etc. Det tekniska gränssnittet omfattar beskrivning av teknikval för de olika implementationerna, t ex protokoll och standarder.
Instans
Här beskrivs en specifik instans av tjänsten, dvs en verklig tjänst som kan hittas via en tjänstekatalog. I denna del av beskrivningen återfinns bl a information som relaterar till drift av tjänsten, t ex tillgänglighet, kontaktperson, etc.
Metamodell komplett:
Metamodell tjänst:
European Interoperability Reference Architecture
Vad är EIRA?
"an architecture content metamodel defining the most salient architectural building blocks (ABBs) needed to build interoperable e-Government systems"
EIRA omfattar alltså endast integration, men på flera nivåer:
Det tekniska lagret tycks utgå från en Application Service som har ett Machine To Machine-gränssnitt och/eller ett Human Interface-gränssnitt. Dessutom stöds den av ett antal komponenter för exempelvis informationsbearbetning, arbetsflöden, dataanalys, applikationsförvaltning o.s.v.
Allmänt om EIRA
EIRA använder Archimate som notation. Man har dock begränsat sig till vissa delar av Archimate. Man har inget krav på att följa Archhimates färgschema eftersom man anser att det begränsar möjligheten att kommunicera effektivt med diagrammen.
Element som EIRA använder i applikations- respektive tekniklagret
Relationer som Eira använder
Specialisering
Eira använder Archimates specialiseringsmöjlighet. Eiras Public Service är en specialisering av Archimates Business Service.
Man inför inga nya symboler för specialiserade element utan stereotypar dem enligt nedan.
Technical application of EIRA
Lyckades inte kopiera bilden nedan i läsbar form, återkommer om det.