Difference between revisions of "SSC Architecture Content Metamodel"

From wiki
Jump to navigation Jump to search
m
(Added security and privacy metamodel element diagrams.)
Line 18: Line 18:
 
==== 5-5-5 Model ====
 
==== 5-5-5 Model ====
 
[[File:SCC MetalModelDraft-V3.5 - 555.png|frameless|575x575px]]
 
[[File:SCC MetalModelDraft-V3.5 - 555.png|frameless|575x575px]]
 +
 +
==== Security ====
 +
[[File:SCC MetalModelDraft-V3.6 - Security.png|frameless|600x600px]]
 +
 +
==== Privacy ====
 +
[[File:SCC MetalModelDraft-V3.6 - Privacy.png|frameless|599x599px]]
  
 
==== Network and Zoning Metamodel ====
 
==== Network and Zoning Metamodel ====

Revision as of 22:29, 23 September 2019

SSC Enterprise Architecture

A content metamodel defines a set of entities that allow architectural concepts to be captured, stored, filtered, queried, and represented in a way that supports consistency, completeness, and traceability (TOGAF 9: 30.2.2)

Our content metamodel is based largely on the TOGAF 9.2 and (primarily) on the ArchiMate 3.0.1 specification, with some specific adaptations and alignment for SSC. In general, unless specified, any relationship permitted in ArchiMate is permitted.

Content Metamodel Diagrams

High Level/Overview

SCC MetalModelDraft-V3.5.png

SSC Services and Segments

SCC MetalModelDraft-V3.6 - Service and Segment.png

Motivation Details

SCC MetalModelDraft-V3.6 - Motivation.png

5-5-5 Model

SCC MetalModelDraft-V3.5 - 555.png

Security

SCC MetalModelDraft-V3.6 - Security.png

Privacy

SCC MetalModelDraft-V3.6 - Privacy.png

Network and Zoning Metamodel

SCC MetalModelDraft-V3.5 - Network and Zoning.png

Object Definitions

Access (relationship)

  • Should have an end arrow from the initiating object to the accessed object. It does not necessarily indicate the direction of the flow of data.

Aggregation (relationship)

  • Indicates that an element groups a number of other concepts, where the other concepts can also be part of other groups. A looser relationship than with a composition.
  • Aggregated items can also be part of more than one aggregation.

Composition (relationship)

  • Indicates that an element groups a number of other concepts, where the other concepts are a fundamental part of the group. E.g.: A cat is composed of a head, body, legs, tail.
  • Composed items can only be part of one composition.

Application Component

  • Should, in the abstract (business/business process cooperation viewpoint) be linked as the representative of the whole application/application system. Used to denote where business roles, functions, processes interact with application systems.
  • In the application layer, its use is similar to that of a function/application module.

Application Data

  • Should, where possible, be linked to a business object.
  • Should be linked to an application process.

Business Actor

  • Represents an actual person, org structure section, committee or working group within or external to the organization. e.g.: Senior Advisor, Director Operations, Senior Vice President, ESSARB, Senior Management Board, Treasury Board, NRCan, John Smith, Dr. Henry Jones. Not: process modeler, designer, client, solution architect, manager
  • Linking: Actors are usually linked to Roles.
  • Naming: A noun. Should be named according to job title or departmental name within Active Directory and/or org chart if applicable.

Business Event

  • Naming: Should be a verb in the perfect tense, e.g: "claim received", usually in the format of subject-verb or object-verb. e.g. "Traffic accident happens" or "Claims form submitted".

Business Function

A logical grouping of related business activity (processes, sub-functions, roles, business information, etc...) No flow or sequence is necessary.

  • Linking: Must (directly or indirectly) support and link to an established Business Capability
  • Linking: Should be associated with an enterprise requirement, strategic outcome, goal, and/or driver.
  • Naming convention: Should NOT use verb-noun naming, in order to not be confused with business processes.

Business Object

  • Naming: Business object names should be nouns, and may have qualifiers if necessary to distinguish. e.g.: Life Insurance Policy Invoice.

Business Process

Something that is done/performed, that has a flow or sequence.

  • Linking: Should be related to a particular (superior) business function (e.g. an SSC Service)
  • Naming: Should name processes with verb-noun notation. "Do something to something". i.e.: Place Order

Business Role

  • Represents an abstract role, not a personal name or defined organizational position, committee, title, rank or hierarchy within the organization. e.g.: process modeler, designer, client, solution architect. Not: Senior Advisor, Director Operations, Senior Vice President, ESSARB, Senior Management Board, Treasury Board, NRCan, John Smith, Dr. Henry Jones.
  • Roles are usually linked to actors and business functions and processes.
  • Naming: Preferably a noun, referring to the primary activity that the role performs. Should be a compound noun to qualify it if it could have multiple meanings. e.g.: claim form completer.

Business Service

Something that is provided to an entity external to the business function.

  • Must link directly (or indirectly through another business service, interface or product) to a client of the related function for the service.
  • Naming: Should use verb ending. May use an "ing" ending. The verb should describe the primary activity of the service, e.g.: "Insurance claim processing".

SSC Services

SSC Services are usually business functions, and should not be represented as ArchiMate business services.

  • Representation: Must be represented as a business function, with category of "client-facing service" or "supporting service"

Name

Relationships: