Difference between revisions of "SSC Artifacts and Diagrams"

From wiki
Jump to navigation Jump to search
(Updating solution architecture portion.)
(Completed updating the artifacts for solution architecture.)
Line 59: Line 59:
 
These diagrams are for service or solution architectures for initiatives.  The solution architecture artifacts are usually captured in a Service and Solution Architecture Description deliverable (package).  These solution architectures are reviewed with enterprise architecture through a governance processes (architecture assurance) to help ensure alignment with the enterprise architecture.
 
These diagrams are for service or solution architectures for initiatives.  The solution architecture artifacts are usually captured in a Service and Solution Architecture Description deliverable (package).  These solution architectures are reviewed with enterprise architecture through a governance processes (architecture assurance) to help ensure alignment with the enterprise architecture.
  
==== Requirements Diagram ====
+
==== Conceptual Solution Architecture ====
 +
 
 +
===== Requirements Diagram =====
 +
Based on ArchiMate Viewpoint:  [https://pubs.opengroup.org/architecture/archimate3-doc/apdxc.html#_Toc489946175 Motivation Viewpoint]
 +
 
 
Key Stakeholders:  Project managers, project teams, business analyst, business architects, service architects, solution architects, engineers.
 
Key Stakeholders:  Project managers, project teams, business analyst, business architects, service architects, solution architects, engineers.
  
Purpose/Value:  List and definitions of the requirements for a project/initiative.
+
Prepared by:  Solution architect, service architect.
 +
 
 +
Purpose/Value:  List and definitions of the requirements for a project/initiative, as well as any related/influencing standards, principles, policies and/or reference architectures.
  
===== Motivation (Benefits Realization) Diagram =====
+
===== Benefits Dependency Map =====
ArchiMate Viewpoint:  [https://pubs.opengroup.org/architecture/archimate3-doc/apdxc.html#_Toc489946175 Motivation Viewpoint]
+
Based on ArchiMate Viewpoint:  [https://pubs.opengroup.org/architecture/archimate3-doc/apdxc.html#_Toc489946175 Motivation Viewpoint]
  
Scope/Constraints:  None.     
+
Scope/Constraints:  Uses motivation elements of outcomes and implementation & migration element of work package and deliverable.     
 +
 
 +
Key Stakeholders:  Project manager/lead, project team, business analyst, benefits realization team, governance bodies, management, executives. 
 +
 
 +
Prepared by: Benefits management in cooperation with the project/service team and/or service/solution architect. 
 +
 
 +
Purpose/Value:  Identify the benefits of a projects/initiative, identifying key performance metrics (KPI's) that will be used to measure success of the effort.  Helps ensure alignment with enterprise outcomes, identify and link requirements to tactical and strategic outcomes. 
  
Key Stakeholders:  Project manager/lead, project team, business analyst, benefits realization team, governance bodies, management. 
+
===== Context Diagram =====
  
Purpose/Value: Identify the benefits of a projects/initiative, identifying key performance metrics, help ensure alignment with enterprise outcomes, identify and link requirements to tactical and strategic outcomes. 
+
Based on ArchiMate Viewpoint:
  
==== Conceptual Architecture ====
+
Key Stakeholders:  Enterprise Architect, Governance Bodies (EART, AC, SARB).
  
===== Solution Context Diagram =====
+
Prepared by:  Service/Solution architect
  
moved - and integrated with the Solution Conceptual Diagram.
+
Purpose/Value:  Identifies the services used and/or modified/created by the initiative.  Identifies and links the initiative to a business capability to be fully or partly realized by the initiative.
  
===== Solution Conceptual Diagram =====
+
===== Conceptual Diagram =====
ArchiMate Viewpoint: Non-Standard (SSC specific)
+
ArchiMate Viewpoint:   [https://pubs.opengroup.org/architecture/archimate3-doc/apdxc.html#_Toc489946170 Layered Viewpoint]
  
Scope/Constraints:  Show no sequence/flow, and generally no associations.  Limited to actors, roles, business functions (key high-level), business information, KPI's.       
+
Scope/Constraints:  Show no sequence/flow, and generally no associations.  Limited to actors, roles, business functions (key high-level), business information, key application components, system software, technology services.       
  
 
Key Stakeholders:  Governance bodies (particularly AC and ESSARB), project teams/leads/managers, executives, enterprise architects, service architects, solution architects.   
 
Key Stakeholders:  Governance bodies (particularly AC and ESSARB), project teams/leads/managers, executives, enterprise architects, service architects, solution architects.   
  
Purpose/Value:  Identifies what, at a high/conceptual level, this project/initiative intends to do (key/main functions), for which clients (roles/actors), and what key information will be required/managed, and what key performance indicators/benefits will be provided by doing the effort.   
+
Purpose/Value:  Identifies what, at a high/conceptual level, this project/initiative intends to do (key/main functions), for which clients (roles/actors), and what key information will be required/managed.   
  
==== Logical/Physical Architecture ====
+
==== Logical (and sometimes physical) Architecture ====
  
===== Business Process Cooperation Diagram =====
+
===== Logical Business Diagram (mandatory) =====
 
ArchiMate Viewpoint:  [https://pubs.opengroup.org/architecture/archimate3-doc/apdxc.html#_Toc489946160 Business Process Cooperation Viewpoint]
 
ArchiMate Viewpoint:  [https://pubs.opengroup.org/architecture/archimate3-doc/apdxc.html#_Toc489946160 Business Process Cooperation Viewpoint]
  
Scope/Constraints:  May only use application components from the application layer.     
+
Scope/Constraints:  May only use application components from the application layer.  May have 1 diagram, or as many in as much detail as is required for the initiative.     
  
 
Key Stakeholders:  Governance bodies (particularly AC and ESSARB), project teams/leads/managers, enterprise architects, service architects, solution architects, business leads, business architects, business analists, business process practicioners.   
 
Key Stakeholders:  Governance bodies (particularly AC and ESSARB), project teams/leads/managers, enterprise architects, service architects, solution architects, business leads, business architects, business analists, business process practicioners.   
Line 99: Line 111:
 
Purpose/Value:  Identifies/defines the business (functions, processes, roles, actors, etc...) of the project/initiative/SSC service, and links to application/data/information layers.   
 
Purpose/Value:  Identifies/defines the business (functions, processes, roles, actors, etc...) of the project/initiative/SSC service, and links to application/data/information layers.   
  
===== Implementation and Deployment Diagram (optional) =====
+
===== Logical Application Diagram (optional) =====
ArchiMate Viewpoint:  [https://pubs.opengroup.org/architecture/archimate3-doc/apdxc.html#_Toc489946164 Implementation and Deployment Viewpoint]
 
 
 
Scope/Constraints:  None.
 
 
 
Key Stakeholders:  Application managers, application architects, service architects, solution architects, CIO office, project team, application developers.
 
 
 
Purpose/Value:  Optional.  Used if more details on application or inter/intra-application and technology interactions are required than is provided in the Technology Usage Diagram (below).
 
 
 
===== Application Cooperation Diagram (optional) =====
 
 
ArchiMate Viewpoint:  [https://pubs.opengroup.org/architecture/archimate3-doc/apdxc.html#_Toc489946162 Application Cooperation Viewpoint]
 
ArchiMate Viewpoint:  [https://pubs.opengroup.org/architecture/archimate3-doc/apdxc.html#_Toc489946162 Application Cooperation Viewpoint]
  
Scope/Constraints:  None.
+
Scope/Constraints:  Must link applications to business processes/functions as defined in the logical business diagram.  Diagram is optional, and is only needed if required to define the application and/or data architecture for the initiative.  Can have as many as are required.
  
 
Key Stakeholders:  Application managers, application architects, service architects, solution architects, CIO office, project team, application developers.
 
Key Stakeholders:  Application managers, application architects, service architects, solution architects, CIO office, project team, application developers.
Line 117: Line 120:
 
Purpose/Value:  Optional.  Used if more details on application or inter/intra-application are required.  Focus on application development/components specifically.
 
Purpose/Value:  Optional.  Used if more details on application or inter/intra-application are required.  Focus on application development/components specifically.
  
===== Technology Usage Diagram =====
+
===== Logical Technology Usage Diagram =====
 
ArchiMate Viewpoint:  [https://pubs.opengroup.org/architecture/archimate3-doc/apdxc.html#_Toc489946166 Technology Usage Viewpoint]
 
ArchiMate Viewpoint:  [https://pubs.opengroup.org/architecture/archimate3-doc/apdxc.html#_Toc489946166 Technology Usage Viewpoint]
  
Scope/Constraints:  None.     
+
Scope/Constraints:  Must link the diagram (with objects within the diagram) to either a logical application diagram (and/or objects), or a logical business diagram (or functions/processes therein).  Optional.  Many have as many as is required to define the technology architecture to the level of detail desired.     
  
 
Key Stakeholders:  Service architects, solution architects, engineers, designers, implementers, operations staff, application support staff and management.   
 
Key Stakeholders:  Service architects, solution architects, engineers, designers, implementers, operations staff, application support staff and management.   
Line 126: Line 129:
 
Purpose/Value:  Maps applications/application systems to required (generic/high level) technology implementations.   
 
Purpose/Value:  Maps applications/application systems to required (generic/high level) technology implementations.   
  
===== Technology Diagram =====
+
===== Logical Technology Diagram =====
 
ArchiMate Viewpoint:  [https://pubs.opengroup.org/architecture/archimate3-doc/apdxc.html#_Toc489946165 Technology Viewpoint]
 
ArchiMate Viewpoint:  [https://pubs.opengroup.org/architecture/archimate3-doc/apdxc.html#_Toc489946165 Technology Viewpoint]
  
Line 143: Line 146:
 
Purpose/Value:  Provides a list of the reference architecture documents available, informing architects of the standard patterns and considerations for preparing architecture in particular defined circumstances.
 
Purpose/Value:  Provides a list of the reference architecture documents available, informing architects of the standard patterns and considerations for preparing architecture in particular defined circumstances.
  
==== Reference Architecture Diagram ====
+
==== Reference Architecture Diagram/Catalog ====
 
ArchiMate Viewpoint:  [https://pubs.opengroup.org/architecture/archimate3-doc/apdxc.html#_Toc489946170 Layered Viewpoint]
 
ArchiMate Viewpoint:  [https://pubs.opengroup.org/architecture/archimate3-doc/apdxc.html#_Toc489946170 Layered Viewpoint]
  
Line 176: Line 179:
 
Purpose/Value:  Used to associate objects, artifacts, deliverables to particular projects/initiatives.
 
Purpose/Value:  Used to associate objects, artifacts, deliverables to particular projects/initiatives.
  
 +
==== Architecture Gaps Catalog ====
 
[[Category:Architecture]]
 
[[Category:Architecture]]
 
[[Category:Enterprise Architecture]]
 
[[Category:Enterprise Architecture]]
 
[[Category:Modeling]]
 
[[Category:Modeling]]

Revision as of 21:36, 22 September 2020

SSC Enterprise Architecture

In addition to a content metamodel, SSC has established a set of specific artifacts (catalogs, matrices, diagrams) that are required. In general, these artifacts follow the recommended viewpoints established in the ArchiMate 3.0.1 Specification. However, in some instances we have chosen diagrams that better suit our particular needs, particularly in respect to project and service governance. The following are the required and recommended artifacts for architecture at SSC.

SSC Key EA Artifacts Diagram

EA Models Structure.png

Strategic Architecture

This portion of enterprise architecture contains artifacts that define the scope of the enterprise, break it down into useful portions (segments), describe the strategic current/target states, drivers and motivations.

Strategic Motivation Diagram

Based on ArchiMate Viewpoint: Motivation Viewpoint

Scope/Constraints: None.

Key Stakeholders: Enterprise architects, business analysts, strategic planning, benefits realization, SSC executives.

Purpose/Value: Used to identify and related the strategic drivers, goals, outcomes of the organization, and the key strategic stakeholders. Provides links to identify what existing and planned architecture are supporting the enterprise's desired target direction. All solution architectures should link (directly or indirectly) to a strategic goal or outcome.

Business Capability Map

Based on ArchiMate Viewpoint: Capability Map

Scope/Constraints: Generally limited to identifying capabilities/sub-capabilities, and their association with enterprise strategic outcomes, goals, drivers.

Key Stakeholders: Senior executives, branches, business managers, enterprise and business architects. Investment prioritization.

Purpose/Value: A primary communication mechanism with SSC executives on the state of the architecture, activities, and progress towards desired target direction. Helps ensure alignment between current/target activities and the strategic direction/capabilities of the organization. Investment prioritization.

Segment Diagram

Based on ArchiMate Viewpoint: Business Process Cooperation Viewpoint

Scope/Constraints: Uses only business roles, business actors, and business functions with categories "SSC Segment", "SSC Client-facing Service", and "SSC Supporting Service". It may begin to associate key high-level roles, information, applications - but generally, it leaves details of architecture to dedicated lower-level diagrams. One diagram per defined segment.

Key Stakeholders: Enterprise architects/Enterprise Architecture management/executives.

Purpose/Value: Enables EA to organize, prioritize and assign architecture work/activities. In particular, it identifies the segments that will be used to organize EA work, and distributes the key services/functions among them. Every identified SSC service should belong to a segment.

Strategic Service Diagram

Strategic Service Diagram: GC Wi-Fi Service

Based on ArchiMate Viewpoint: Layered Viewpoint

Scope/Constraints: This diagram defines, at a high level, an SSC service. It links the SSC Service to Business Capabilities (1 or more), and to other key business functions/services, and to the key foundational/supporting technologies. The diagram may expose some of the key sub-functions/processes that are performed in that SSC service (down 1 level of conception). Detailed business, application, information and technology diagrams for a particular service are to be detailed in other (solution-level) diagrams.

Key Stakeholders: Enterprise architects/Enterprise Architecture management/executives, Service architects.

Purpose/Value: Provides a conceptual view of SSC Services, key inter-service linkages, strategic linkages, and links to enabling technologies. Answers the questions: 1) What services/functions need which services to operate?, 2) What technologies are required by a particular SSC Service?

Service Roadmap Diagram

Based on ArchiMate Viewpoint: Layered Viewpoint

Scope/constraints: Uses Implementation and Migration elements, and Motivation elements (goal/outcome).

Key Stakeholders: Enterprise Architects, Service Architects, Solution Architects, Service leads/teams.

Purpose/Value: Defines/describes the different architectures for a particular service in defined states (n-2, n-1, n, n+1, n+2) and plateaus (current, target, target+), and what work packages (projects) will satisfy which identified architecture gaps.

Solution (including Service) Architecture

These diagrams are for service or solution architectures for initiatives. The solution architecture artifacts are usually captured in a Service and Solution Architecture Description deliverable (package). These solution architectures are reviewed with enterprise architecture through a governance processes (architecture assurance) to help ensure alignment with the enterprise architecture.

Conceptual Solution Architecture

Requirements Diagram

Based on ArchiMate Viewpoint: Motivation Viewpoint

Key Stakeholders: Project managers, project teams, business analyst, business architects, service architects, solution architects, engineers.

Prepared by: Solution architect, service architect.

Purpose/Value: List and definitions of the requirements for a project/initiative, as well as any related/influencing standards, principles, policies and/or reference architectures.

Benefits Dependency Map

Based on ArchiMate Viewpoint: Motivation Viewpoint

Scope/Constraints: Uses motivation elements of outcomes and implementation & migration element of work package and deliverable.

Key Stakeholders: Project manager/lead, project team, business analyst, benefits realization team, governance bodies, management, executives.

Prepared by: Benefits management in cooperation with the project/service team and/or service/solution architect.

Purpose/Value: Identify the benefits of a projects/initiative, identifying key performance metrics (KPI's) that will be used to measure success of the effort. Helps ensure alignment with enterprise outcomes, identify and link requirements to tactical and strategic outcomes.

Context Diagram

Based on ArchiMate Viewpoint:

Key Stakeholders: Enterprise Architect, Governance Bodies (EART, AC, SARB).

Prepared by: Service/Solution architect

Purpose/Value: Identifies the services used and/or modified/created by the initiative. Identifies and links the initiative to a business capability to be fully or partly realized by the initiative.

Conceptual Diagram

ArchiMate Viewpoint: Layered Viewpoint

Scope/Constraints: Show no sequence/flow, and generally no associations. Limited to actors, roles, business functions (key high-level), business information, key application components, system software, technology services.

Key Stakeholders: Governance bodies (particularly AC and ESSARB), project teams/leads/managers, executives, enterprise architects, service architects, solution architects.

Purpose/Value: Identifies what, at a high/conceptual level, this project/initiative intends to do (key/main functions), for which clients (roles/actors), and what key information will be required/managed.

Logical (and sometimes physical) Architecture

Logical Business Diagram (mandatory)

ArchiMate Viewpoint: Business Process Cooperation Viewpoint

Scope/Constraints: May only use application components from the application layer. May have 1 diagram, or as many in as much detail as is required for the initiative.

Key Stakeholders: Governance bodies (particularly AC and ESSARB), project teams/leads/managers, enterprise architects, service architects, solution architects, business leads, business architects, business analists, business process practicioners.

Purpose/Value: Identifies/defines the business (functions, processes, roles, actors, etc...) of the project/initiative/SSC service, and links to application/data/information layers.

Logical Application Diagram (optional)

ArchiMate Viewpoint: Application Cooperation Viewpoint

Scope/Constraints: Must link applications to business processes/functions as defined in the logical business diagram. Diagram is optional, and is only needed if required to define the application and/or data architecture for the initiative. Can have as many as are required.

Key Stakeholders: Application managers, application architects, service architects, solution architects, CIO office, project team, application developers.

Purpose/Value: Optional. Used if more details on application or inter/intra-application are required. Focus on application development/components specifically.

Logical Technology Usage Diagram

ArchiMate Viewpoint: Technology Usage Viewpoint

Scope/Constraints: Must link the diagram (with objects within the diagram) to either a logical application diagram (and/or objects), or a logical business diagram (or functions/processes therein). Optional. Many have as many as is required to define the technology architecture to the level of detail desired.

Key Stakeholders: Service architects, solution architects, engineers, designers, implementers, operations staff, application support staff and management.

Purpose/Value: Maps applications/application systems to required (generic/high level) technology implementations.

Logical Technology Diagram

ArchiMate Viewpoint: Technology Viewpoint

Scope/Constraints: None.

Key Stakeholders: Service architects, solution architects, engineers, designers, implementers, operations staff.

Purpose/Value: Identifies/defines the required technology components, positioning/placement/location, relationships, network, network zoning required for the initiative.

Reference Library

Reference Architecture Catalog

Key Stakeholders: Enterprise architects, service architects, solution architects, engineers/implementers.

Purpose/Value: Provides a list of the reference architecture documents available, informing architects of the standard patterns and considerations for preparing architecture in particular defined circumstances.

Reference Architecture Diagram/Catalog

ArchiMate Viewpoint: Layered Viewpoint

Scope/Constraints: None.

Key Stakeholders: Enterprise architects, service architects, solution architects, engineers/implementers.

Purpose/Value: Diagrams of reference architecture patterns/options, to illustrate patterns and considerations for preparing new architectures under particular defined conditions/circumstances. Used to ensure alignment/compliance and consistency of implementations.

IT Standard Catalog

Key Stakeholders: Enterprise architects, service architects, solution architects, engineers/implementers.

Purpose/Value: Provides a list of IT Standards to be applied to architectures, designs and implementations at SSC. Used to ensure alignment/compliance and consistency of implementations.

Content Metamodel Diagram

ArchiMate Viewpoint: Layered Viewpoint

Scope/Constraints: None.

Key Stakeholders: Enterprise architects, service architects, solution architects, engineers/implementers.

Purpose/Value: Illustrates the valid relationships amongst all types of architecture objects, and the rules to be applied for their use in architecture models. The model of the model for architecture.

Lexicon Catalog

Key Stakeholders: All users and practitioners of architecture.

Purpose/Value: Provides definitions of terms/nomenclature used for architecture.

Initiative (Project) Catalog

Key Stakeholders: Executives, project managers/leads, project teams, enterprise architects, service architects, solution architects, governance bodies, engineers.

Purpose/Value: Used to associate objects, artifacts, deliverables to particular projects/initiatives.

Architecture Gaps Catalog