251
edits
Important: The GCConnex decommission will not affect GCCollab or GCWiki. Thank you and happy collaborating!
Changes
Jump to navigation
Jump to search
Line 59:
Line 59: − + + + + + − + + + − + − + − + + + + + + + − Key Stakeholders: Project manager/lead, project team, business analyst, benefits realization team, governance bodies, management. + − 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. + − ==== Conceptual Architecture ====+ − ===== Solution Context Diagram =====+ − moved - and integrated with the Solution Conceptual Diagram.+ − + − + − + − + − + − + − + Line 99:
Line 111: − + − 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) ===== − + Line 117:
Line 120: − + − + Line 126:
Line 129: − + Line 143:
Line 146: − + Line 176:
Line 179: +
SSC Artifacts and Diagrams (view source)
Revision as of 20:36, 22 September 2020
, 20:36, 22 September 2020Completed updating the artifacts for solution 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.
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.
===== 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.
===== 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.
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#_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.
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.
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]
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]
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]]
