SSC Architecture Content Metamodel

Please note that this page is no longer being updated and the information appearing on these pages is no longer current.

For information about SSC's Enterprise Architecture practice, please see: Architecture Centre of Excellence - Centre d'excellence en architecture - Home

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

SSC Services and Segments

Motivation Details

5-5-5 Model

Security

Privacy

Network and Zoning Metamodel

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

Capability

A capability represents an ability that an organization, person, or system possesses. We primarily use capabilities in capability maps, that allow architecture to present a higher-level more strategic and conceptual view of the state of the enterprise, and to help with decision-making.

• Linking: Capabilities can link to other capabilities (e.g. parent/child) - indicated with serving relationships.
• Linking: Business functions should link and be linkable to capabilities (realize). Capabilities should realize outcomes or goals in the motivation layer.
• Linking: Only business functions from the core elements should link to capabilities.l
• Tend to be more abstract than most SSC services, functions, processes.

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"
• Naming: As defined by SSC Service Management Framework.
• SSC Services (or their sub-functions) should always be linked to one or more Capabilities.