Skip to content

Artefacts, Reviews and Approvals

|Section/category| Artefacts | Location / Tool | Type of approval | Approval 
 Sign (S) 
 Acknowledge (A)| QA Approval 
 Sign (S) 
 Acknowledge (A) | Review | Consult & Inform|  |--|--|--|--|--|--|--|--| |Products|  IT Risk Assessment| ServiceNow   | (A) | SO | No | QA |PDL, Platform Architect, SM| | | KaaS Products: Requirement Specification|  ADO KaaS | PR | SO delegate (A)  | No | QC + Platform Architect | PDL & SM| | | Work Item ‘URS’ |  ADO KaaS |  WIFA | PDL (A) | No | QC + Platform Architect |SM + QA| | | KaaS Products: Solution Designs - High Level solution |  ADO KaaS |  PR | PDL (A) | No | QC + Platform Architect |-| | | KaaS Products: Detailed Documentation (design, operation guide) - per product (pipelines, audit log-forwarder etc.) - GIT PRs |  ADO KaaS |  PR | Platform Architect (A) | No | Peer review |PDL & SM| | | KaaS Products: Code Reviews - per product (pipelines, audit log-forwarder etc.) - GIT PRs |  ADO KaaS |  PR | KaaS Codebase SME (A) | No | Peer review| Platform Architect| | Platform Build | Kaas Platform Handbook: Build (config guides, service accounts, connectivity & PIM) |  ADO KaaS |  PR | Platform Architect (A)| No | Peer review |QC+SM| | Platform Releases| Kaas Platform Handbook: Releases (Approvals, test-traceability matrix, defects handling etc.) |   ADO KaaS | PR | Platform Architect (A) + QC | No | Peer review |SM| | |CIL |ADO KaaS |  WIFA| SM (A) | No | QC + Peer review| Platform Architect |   | |KaaS Test plans (IV, OV, Performance protocols, p-IV)| ADO KaaS | WIFA| Platform Architect (A) | No | Peer review| QC, SM | | |Test cases |ADO KaaS |  WIFA| Platform Architect (A) | No | Peer review|- |     | |Test runs |ADO KaaS |  AVP| QC (A) | No | Peer review|- |   | |Test Defect |  ADO KaaS|  WIFA| QC (A) | No | Peer review| Platform Architect| | |Test reports - Test execution review, conclusion and approval Test case| ADO KaaS| AVP|QC (A) | No | Peer review| Platform Architect, PDL & SM | |Platform Operations| SOP: KaaS Operation and Maintenance | QualityDocs |  ES | SM (S) | Yes (S) |  Peer review| QC, PDL & Platform Architect| | |Onboarding Agreement(s)  | QualityDocs |  ES |  SM (S) | No | Peer review | PDL| | |Service Agreement(s) | QualityDocs | ES | PDL + SM (S) | No  | Peer review |QC| | |IT PSE Report | QualityDocs | ES | SM (S) | No  | Peer review |QC| | |Supplier Assessment | QualityDocs | ES | SM (S) + SO delegate | No  | QA + Peer review |QC + Platform Architect| | |SOC 2 Review Reports | QualityDocs | ES | SM (S) + SO delegate | No  | Peer review |QC + Platform Architect| | |Changes in ServiceNow | ServiceNow |(A) | SM (A) | No | QC | PDL & Lead Architect| | |ITOM and ITSM System Descriptions and Config | ServiceNow| (A)|PDL (A) or SM (A) | No | Peer review| QC | | | Kaas Platform Handbook: Operations |   ADO KaaS | PR | Platform Architect (A) or SM  | No | Peer review |SM + QC| | Project Handbook | Kaas Project Handbook |  ADO KaaS |  PR | Platform Architect (A) | No | Peer review| SM + QC| | Support Runbook | Kaas Support Runbook |  ADO KaaS |  PR | ADO Operator (A) | No | Peer review| -| | Pipeline Execution (PRD) | Deployment approvals of platform-pipeline|  ADO KaaS   | ENVA | Platform Architect (A)  | No | - |PDL & SM| | | Deployment approvals of other pipelines (access-mgmt, stream-gov, pipeline-agent etc.)|  ADO KaaS   | ENVA | Platform Operator (A)  | No | - |-| | | Pipeline Input Configuration (e.g. adding Teams/namespaces, Service Accounts, Tags) reviews - GIT PR |  ADO KaaS |  PR |  Platform Operator (A) | No | Peer review|-|      | Initial Setup | Implementation Plan and Report  |  QualityDocs|  ES | SO delegate (S) - PM | Yes (S) | Peer review |PDL & Lead Architect| | |Design Review Report | QualityDocs |  ES | PDL (S) | No | Peer review |Lead Architect|         | |IT Periodic System Evaluation | QualityDocs |  ES | SO delegate (S) - PM | No | Peer review |-| | |IT Delegation Agreement  | QualityDocs | ES | BO (S) | No | Peer review |-| | |MAP Solution Designs (including traceability from RS to Design) |ADO MAP-CS|  PR|Lead Architect (A) | No | QC | PDL|   | |MAP Functional Specifications | ADO MAP-CS |  PR| Lead Architect (A) |  No | QC | PDL| | |MAP Design Specifications  | ADO MAP-CS|   PR| Lead Architect (A)|  No | Peer review |-| | |MAP Operation Guides  | ADO MAP-CS|  PR| Lead Architect (A)| No | Peer review|-| | |MAP Configuration Item Lists  |ADO MAP-CS| PR|  Lead Architect (A) |  No | QC + Peer |PDL & SM| | |MAP Code reviews - code in GIT will be reviewed by PR  |ADO MAP-CS | PR | Lead Architect (A)| PR|  Peer Review  | -|  | |MAP Test plans (UIT)| ADO KaaS | WIFA|PDL (A) | No | Peer review| QC, SM |

  • QA generally will not be involved in CHG review process in ServiceNow but if there are any impact to URS (creation or updation), QA will review/approve the Change in ServiceNow (via CHG extract in QualityDocs) along with SO (SO Delegate) at Plan and Report phase.
  • QA will also be involved in KaaS release changes as per the Manage IT Infrastructure [Q216301] in Operation phase.
  • Either the Product Owner or the Service Manager, depending on which is involved in the approval of the artefacts listed in the above table, will only approve the document in conjunction with other approvers.

Abbreviations for Approvals

Abbreviations Description
(S) Signature
(A) Acknowledgement
ES Electronic Signature
ER Electronic Record
PR Pull Request
WICL Work Item to Closed
WIFA Work Item to Final Approved
ENVA Environment Approval
AVP Approved Via Pass

Usage of ADO for Documentation in KaaS

KaaS utilizes Azure DevOps for storage of documentation. Documentation is written in markdown files and stored in GIT repositories. Detailed technical documentation is stored in the same repositories as the source code and configuration, and requirements, high-level solution design, platform operation guides and project guidance is stored in the 'Wiki' repository.

The 'main' branch acts as the approved version of documentation. If a change or new addition is required to a page, a new branch should be created. The new branch can then be published and worked on, and once ready for merge to main, a Pull Request (PR) must be made.

For the 'Product' section in the Wiki, in order to increase ease-of-reading traceability, documentation headers and footers should be updated with PR reference and changelog details, including a ServiceNow CHG ID where necessary.

For the remaining sections, the built-in GIT functionality ensures extensive traceability and comparison of changes and updates between file versions, but no distinct header and changelog is needed.

Policies can be configured for certain areas within documentation, ensuring that certain roles or individuals must approve PR merges into the main branch. These are configured by ADO Project administrators. The policies reflect the approvals in above artefacts and approval tables.

You need to have 'Contributor' role in order to create new branches and PR for documentation merges.