| Line 1: |
Line 1: |
| − | '''Please note that this page is no longer being updated and the information appearing on these pages is no longer current.'''
| + | {{Delete|reason=Expired content.}} |
| − | | |
| − | '''For information about SSC's Enterprise Architecture practice, please see: [[/163gc.sharepoint.com/sites/ACoE-CEA/SitePages/Home.aspx|Architecture Centre of Excellence - Centre d'excellence en architecture - Home]]'''[[File:EA Sticker.png|alt=SSC Enterprise Architecture|right|frameless|225x225px]]
| |
| − | 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 <small>([https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap30.html#tag_30_02 TOGAF 9: 30.2.2])</small>
| |
| − | | |
| − | Our content metamodel is based largely on the [https://pubs.opengroup.org/architecture/togaf9-doc/arch/index.html TOGAF 9.2] and (primarily) on the [https://pubs.opengroup.org/architecture/archimate3-doc/ 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 ====
| |
| − | [[File:SCC MetalModelDraft-V3.5.png|frameless|1173x1173px]]
| |
| − | ==== SSC Services and Segments ====
| |
| − | [[File:SCC MetalModelDraft-V3.6 - Service and Segment.png|frameless|691x691px]]
| |
| − | ==== Motivation Details ====
| |
| − | [[File:SCC MetalModelDraft-V3.6 - Motivation.png|frameless|1198x1198px]]
| |
| − | ==== 5-5-5 Model ====
| |
| − | [[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 ====
| |
| − | [[File:SCC MetalModelDraft-V3.5 - Network and Zoning.png|frameless|648x648px]]
| |
| − | | |
| − | === 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.
| |
| − | [[Category:Architecture]]
| |
| − | [[Category:Enterprise Architecture]]
| |
| − | [[Category:Modeling]]
| |