Guideline

Development and Operation (DevOps)

13 April, 2023
Document Type: Guideline
Document Classification: Public
Issue No.: 1.0
Document No.: DGA-1-2-2-208
 Table of Content

01 Introduction …………………………………………………………………….... 3

02 Guideline Objectives …………………………………………….………….….. 4

03 Guideline Scope ………………….…………………...……………………..... 4

04 Target Audience………………….………………………………………….….. 4

05 Guideline Statement ……………..………………………………………….….. 5

5.1 DevOps Approach Background ……………………………….……….…. 5

5.1.1 DevOps Application Purpose/Value ………................................……. 7

5.1.2 DevOps Use Cases …..………………………..…………………...…….. 8

5.1.3 DevOps Approach Phases …….........................................…………… 9

5.1.4 DevOps Approach Requirements ....................................................... 17

5.1.5 DevOps Approach Adoption …..………………................................. 22

5.1.6 DevOps Approach Sustainability & Measurement …………………… 27

06 Table of Definitions ……………….…………………………………………….. 30

07 Table of Abbreviations ……………………………………………………..…… 32

2
 Introduction

Driven by the role of the Digital Government Authority (DGA) to enhance digital
performance within government entities, raise the quality of services provided and
improve the beneficiary's experience, in line with the strategic directions of the DGA,
and in practice of the best international practices in all digital government-related areas,
the DGA has prepared a "guideline for the development and operation approach
(DevOps approach)" to increase the efficiency of digital services and products, by
adopting a cooperative or joint approach to accomplish the tasks performed by the
application development and IT operating teams in the government entity. The DevOps
approach is the most advanced way to develop and maintain IT systems, combining end-
to-end ownership of engineering and automation. Hence, this guideline is one of the
references that will contribute to promoting the adoption and use of the DevOps
approach in support of digital transformation activities in the government sector. In
addition, this guideline is part of a series of guideline documents aimed at supporting
and promoting digital excellence.

3
 Guideline Objectives
This guideline aims to:

Encourage government Learn the effective

entities to adopt DevOps Understand the DevOps
measurement of DevOps
approach , which in turn will: approach requirements for
approach adoption
§ Enhancing communication the effective implementation
and interaction between
software developers and
operators and project
management experts
§ Reduce costs and improve
productivity at a faster rate
§ Execute related processes
more reliably and
efficiently

Guideline Scope
The scope of DevOps approach guideline divided into 7 sections as follow:

DevOps DevOps DevOps DevOps

approach approach approach approach
background Purpose/Value cases phases

DevOps DevOps DevOps approach

approach approach sustainability &
requirements adoption measurement

Target audiences
This guideline targets experts, practitioners and technical personnel working in
software/system development in government entities.

4
 Guideline Statement
5.1 DevOps Approach Background

In the past, most software development has proceeded in a “waterfall approach” with a strict
separation of the phases of the software development as well as the operation of software (e.g.,
administration, patching, and maintenance). This traditional divide has caused several key
challenges.

Missing collaboration between

Missing ability to react to the different teams as part of
beneficiaries feedback the software development to
ensure overall success

Missing focus on the stability

Overly complex and interfaces
and the run of software versus
between the different steps of
the development of new
the software development.
features and assets.

5
 These different challenges have led software developers to reconsider the traditional ways of
developing software and to adopt new ways of working.

Single team mindset: moving away from silo-based processes and interactions
towards end-to-end delivery and collaboration in fully empowered products
teams.

Equality of non-functional requirements: : involvement of the right experts and

measurement of software reliability to ensure proper and resilient operation of
the software.

Continuous improvement: moving away from manual rework and finger pointing
towards a continuous improvement of the existing software.

Fact-based decision: moving away from decision being taken by misaligned KPIs
and non-fact-based decisions towards basing all decision on software
development on data and proper aligned analysis.

Sharing culture: moving away from kept secrets and individual developments
towards cross-team collaboration and alignment to ensure mutual success.

Engineering practices: moving away from bespoke and hard-to-reproduce assets

towards properly engineered solutions.

Automation: moving away from manual controls and manual monitoring towards
automation of the controls and monitoring to ensure production of first-time-right
products.

6
 5.1.1 DevOps Approach Purpose/Value
The specific purpose of DevOps is It included achieving the following:

Generate faster results Provide a better experience

that are more tailored to and more clear direction to
beneficiaries the development teams

This is specifically required caused by Digital transformation. Digital is changing customer

behaviors and technology expectations, while exponentially increasing pressures
on IT demand, costs, and delivery. This is also generating the value of DevOps as the
enablement of Digital transformations is a key requirement to stay competitive and meet citizen
demands in the future.
The Omni-channel experience is now the norm, creating new expectations for digital delivery.
Citizens are now hyper-informed, with new products, services, and features made continuously
available to them through mobile devices and apps. Furthermore, citizens expect service and
interaction 24/7, placing increasing pressure on IT services.
These expectations are increasing the pace and complexity of software and infrastructure
change. Server and storage demand, for example, have risen 10 times because of the vast
volumes of new data and real-time machine learning analytics. The cost to deliver and maintain
digital solutions has increased by two to three times, due to duplicative systems, costly legacy
architecture, and dual maintenance support. To adapt to rapidly changing customer
expectations while maintaining quality, government entities are implementing DevOps.

The value of implementing DevOps approach compared to the traditional ways has the
following outcomes:

Faster time to market: from typically 15-50 days for deployments to production to 15-
20 minutes (typically due to automation of the server deployment and the software
build and test).

Higher efficiency: a productivity increase of development teams of 30% (typically due

to more efforts being first-time-right).

More stability: reduction of critical incidents by around 70% (typically due to better
monitoring and higher code quality).

Greater employee satisfaction, as a culture of autonomy and self-steering.

7
 5.1.2 DevOps Use Cases
The government sector is slowly adopting the principles of the "DevOps" approach, and in general, most
government entities have recently begun to explore the "DevOps" approach instead of using the (old)
waterfall methodologies in developing most software products. Examples of adopting the "DevOps"
approach in government entities include:

Large-scale projects: Several large-scale software projects in the government sector are
currently using DevOps approach as a method for improved efficient delivery project
delivery. Specifically, for software developments where the final goal is ambitious and less
clear (e.g., development of a national identity solution, citizen apps, national platforms,
etc.).

Resilient operation: The important of adopting DevOps approach arise where resiliency in
operation is a key. It is crucial to ensure changes do not impact the operations of the actual
product.

Interface development: The delivery of updated interfaces (e.g., for mobile apps for
government services) is a typical candidate to pilot usage of DevOps approach principles
because of the frequent changes and the fast visibility of faster delivery.

8
 5.1.3 DevOps Approach Phases
The ISO/IEEE have defined clear phases for the rollout of DevOps approach within an entity as part of
ISO 32675. It defines the different phases of the DevOps approach introduction as well as the
execution of the phases. DevOps approach requires a significant mindset shift and upskilling of the
workforce instead of just implementing new processes and tools.
In the following parts, this section summarizes the insights both from a perspective of ISO standard as
well as best practices that have been observed in the industry that include the following:

Package/
Plan Create Verify
Pre-prod

Set a plan for how to Develop the Manage and ensure Make the product/
develop the actual the quality of the service ready to be
application/ the software delivered code and deployed.
service and its codes. further end
further products.
development.

Release Configure Monitor

Ensure that Configure the Monitor the

software codes application and the underlying
can be delivered underlying performance health
to production. infrastructure of application and
components. the hardware usage.

9
 Plan
Planning includes the definition referring also to the planning of the business value as well as the
possible application of the software.

Key activities:

Collection of production metrics (including SLAs/service-level objectives [SLOs]) and

01 feedback.

02 Requirements definition (use case, prototyping).

03 Collection and definition of business metrics

04 Update of release metrics.

05 Definition of release plan (timing, business case).

06 Definition of security policy, adherence, and requirements.

Identification and role definition for key stakeholders from business, IT, software
07 development, and architect teams.

Example of “Plan” Tools:

Trello Pivotal Tracker Basecamp Monday.com

Atlassian Azure DevOps

Atlassian Jira
Conference Approach

10
 Create

The creation phase includes the actual coding, building and the actual configuration of the software
product so that all the software development process should be completed.

Key activities:

01 Design of the software and architecture (software, configuration).

02 Develop software code as well as code merge, code quality, and performance.

03 Build and monitor building performance.

04 Perform functional tests.

05 Release software to production.

Example of “Create” Tools:

GitHub GitLab CircleCi

Atlassian Bamboo AWS CodeBuild Jenkins

11
 Verify
Ensures the quality of software releases and code quality, with the highest quality software being
deployed to production.
Key activities:

01 Performance of acceptance tests.

02 Performance of regression tests.

03 Performance of static analysis (quality and compliance).

04 Performance of security analysis (vulnerability).

05 Conducting performance tests.

06 Conducting configuration tests.

Example of “Verify” Tools – test automation:

Selenium Jest Lamdatest Jasmine TestComplete Pytest

\ Example of “Verify” tools - Static analysis:

SonarQube Raxis SmartBear Collaborator

Example of “Verify” tools - security test:

OWASP Fuzz Wapiti w3af SonarQube

12
 Package/Pre-prod

Involves the activities once the release is ready for deployment, also referred to as packaging or staging.

Key activities:

01 Management to get the required Approvals/pre-approvals .

02 Release package configure.

Management of automated releases (for example, application release is

03 automatically pushed).

Management of triggered releases (for example, upon a "ready state" being

04 met).

05 Release staging and holding.

Example of “Package/Pre-prod” Tools:

Azure DevOps Approach Atlassian Bamboo Jenkins

CircleCi Codeship

13
 Release
Includes scheduling, orchestration, provisioning, and deploying software into production and targeted
environment. This aspect of the toolchain includes application release/deployment automation and
release management.

Key activities:

01 Release coordination.

02 Management of scheduled/timed releases.

03 Deploying and promoting application.

04 Management of change controls.

05 Management of fallbacks and recovery.

Example of “Release” Tools:

Azure DevOps AWS

GitLab Ansible Chef
Approach CodeBuild

14
 Configure
Includes activities for infrastructure provisioning, configuration of additional IT, post software
deployment.

Key activities:

Infrastructure provisioning and configuration (including storage, database, and

01 network).

02 Application provisioning and configuration.

Solutions that facilitate above activities are tools around continuous configuration
03 automation, configuration management and infrastructure as code.

Example of “Configure” Tools:

Terraform Puppet Labs Docker

Chef Helm HelmAnsible

15
 Monitor

Includes application performance monitoring, infrastructure monitoring, and alerting tools.

Key activities:

01 Performance and availability of the IT infrastructure, network, and application.

02 End-user response and experience.

03 Production load metrics gathering.

04 Often provides inputs to ‘plan’ activities required for changes, new release cycles.

Example of “Monitor” Tools:

Amazon
New Relic Splunk Sumo Logic
CloudWatch

Google Cloud Prometheus Sensu

16
 5.1.4 DevOps Approach Requirements
To run DevOps approach at scale and capture its full potential, there are several prerequisites that
need to be in place. The approach is typically implemented in two phases: top-down and bottom-up
phase. The objective of the top-down phase is to define the overarching vision and create the “case for
change” in the entity, while the bottom-up phase concerns the actual implementation of DevOps
approach methods/tools in the individual product or development teams.

Checklist for the top-down phase:

An organizational model needs to be in place that shows the development teams as well
01
as their integration with the operations teams

The organizational and operating model needs to clarify both aspects: the reporting
02 lines as well as the performance appraisal process including all key team members from
business, development as well as operations

03 Appropriate architecture principles (e.g., interfaces via APIs) need to be formulated and a
plan must be developed to realize the target system architecture for the systems needed
to implement DevOps approach (key aspects of the target architecture are further
elaborated below)

Develop a plan to adopt approach tools and design a rollout plan for its implementation

Provide required talent in terms of infrastructure, development and operation for the
down-top pilot phases and develop a plan for additional recruitment.

17
 The system architecture for DevOps approach can be characterized by different enablers that come
together. The enablers are:

Collaboration platforms include the source code management, work item

management, the documentation as well as the management of incidents. It
01 also includes tools to chat and perform post-mortem management as well as
the required dashboards and reporting.

Implementation and operations tracks include the different tools directly

02 supporting the DevOps approach phases that we have elaborated on above.

03 Management tools include asset and financial management tools.

PaaS services include the direct provisioning of infrastructure as databases,

04 middle ware and focused specific tools for APIs.

Infrastructure provisioning includes the relevant tools for the provisioning of

05 storage, network and servers.

18
 Further developments during the bottom-up phase need to be completed. The below checklist
marks their key elements.

Checklist for the bottom-up phase:

A DevOps approach guideline needs to be defined including the key processes

01 (development, finance, capacity and portfolio planning, infrastructure management
etc.) and their respective steps in the future DevOps approach organization.

An engineering support team set up to drive and support the DevOps approach
02 transformation.

The required capacity for further pilots needs to have been established and a further
03 hiring plan for capacity is set up.

After successful completion of these two phases, the government entity can move into the actual
adoption of DevOps approach within the entity (see next chapter). This entails two key cultural shifts
that are required to truly see the required changes in the team-operating model.

19
 Culture of ownership:

Teams run products as small businesses with the following qualities:

A single team mindset: Autonomous teams are accountable for a clearly defined
01 product and cover the full IT value chain, including deployment and operations.

Treating development, quality, security, scalability, and reliability as equally

02 important.

03 Continuously improving its members, product, and ways of working.

04 Taking fact-based decisions.

Best practices and learnings are shared internally and externally in a blameless way,
05 open-source technologies are leveraged, and contributions are shared back.

20
 Technical practices and automation:

Teams use modern engineering practices and push automation by doing the following:

Using modern engineering practices to make collaboration within and between teams
01
easier.

02 Taking an “automate everything” approach.

03 Adopting fully automated testing and a continuous delivery system

These techniques typically lead to an increased productivity.

21
 5.1.5 DevOps Approach Adoption
After completing the top-down and bottom-up phases, the government entity can move into the
onboarding of teams to the DevOps methodology. To build DevOps capabilities quickly and at
scale, government entities should define a repeatable approach.

A successful DevOps roll-out combines both ‘top-down’ and ‘bottom-up’ approach. It over-invests
in cultural transformation, as this is the most challenging part of the DevOps journey. While the
weighting of top-down vs. bottom-up initiatives is highly dependent on the context, they should
include the following best practices:

Top-down approach

The top-down approach follows a series of steps:

01 Determine target design, based on key design choices.

02 Define vision and aspiration in line with business objectives.

Establish structured and frequent communication using a variety of formats (for

03 example, townhall, team visits), coaching and role modelling of management
based on “servant leadership” principles..

Implement capability building programs covering both formal training and

04 informal events to upskill existing talent, recruitment of cross-functional and/or
DevOps approach experts.

22
 Bottom-up approach

In the bottom-up approach, DevOps approach is implemented team-by-team in a repeatable way,

following a series of steps:

Pilot the rollout approach team-by-team based on business priorities and potential
01 impact.

Follow structured roll-out and/or scale-up plan to cover full government entity,
02 structured approach to develop tools/best practices in teams.

Implement a pre-defined set of technical changes executed as a continuous

03
improvement journey.

Adopt approach for pilot applications: Most government entities focus on

04 demonstrating impact with selected practices for three to five pilot applications first,
then later extend the toolbox iteratively and prioritize in relation to the ‘pain’ of
increasingly frequent releases.

Pilot Phases
Pilot phases are essential to test the approach in the top-down approach before the bottom-up
approach is executed at a large scale. Team-by-team transformation is based on business priorities
and/or potential impact. The pilot phases adopt the following two steps as essential best practices:

Shifting the culture by aligning objectives across development and operations

01 teams, raising awareness about equal importance of the stages in the app’s lifecycle,
and sharing best practices (for example, in code development) and learnings.

Aligning and integrating engineering practices and automation in the team by

02 agreeing on approaches to code development, building the foundations to
integrate automated testing, and starting to continuously deliver with one-click
automated releases to customers.

23
 Roll-out roadmap

It is essential for the rollout to build internal coaching capabilities on both “soft” and “hard”
automation skills by creating sufficient internal knowledge to support the adoption of DevOps
approach. This needs to be owned also by internal resources.

The rollout typically happens in 4 phases. The top-down planning typically not exceed 4-6 weeks
whereas the pilot and bottom-up planning can also partially overlap but can extend over 4-6
months up to multiple years depending on the scope. The rollout scope can afterwards be
extended over time. It also requires taking into account the required technology prerequisites to
roll out the model to the entire government entity.

It should be noted that the model for the rollout of DevOps approach should be unified within in
each government entity. Keeping multiple models makes alignment more difficult and creates
unnecessary interfaces. The adoption is fostered through two practices that are observed as
essential for successful rollout.

24
 1- A high intensity learning process

A high intensity process can increase DevOps approach capabilities within teams. This could include
dedicated time for improvements in bursts of two to four acceleration sprints.

Typically, the preparation includes acceleration sprints with the team to ensure:

Clarity on aspiration for the overall software development in terms of both functional
01 and non-functional requirements.

02 Availability of the right resources (min. 50 percent of team time).

03 Availability of required DevOps approach and Cloud engineers.

The acceleration sprints then according to best practice proceed via first the introduction to the
working practices. These working practices include the process design, the change management as
well as key processes as incident management as well as the development itself.

Similarly, it is common to see that the acceleration sprints should cover the relevant key elements of
tooling and technology introducing the relevant tools that will be introduced as well as the key
aspects thinking about the development processes. This specifically includes the coverage of
automated testing as well as working with a CI/CD track. It should also include a clear introduction to
the architecture target picture as well as the roadmap to get there. Finally, during the acceleration
sprints the team should already work together and show key parts of the agile ceremonies as e.g.,
the sprint demos for the content that teams have learned.

25
 2- Team capability model

The government entity would also need to establish the capability to work as a team between the
development and the operations teams. Building this capability requires proceeding in phases
and requires handing over responsibilities to the DevOps approach teams in phases. In terms of
capability building, a common model is that the capability built by changing the operating model
in phases.

The first phase is the co-location of the development and operations teams. In this phase agile
working practices are in place for development and the relevant automations for testing and
code quality checks are implemented. However, the tracking of dependencies and the
deployment still require manual controls and approvals. This means that development and unit as
well as acceptance testing become part of the DevOps approach team whereas deployment and
release as well as all additional infrastructure and operations tasks will remain separate.

In the second phase the operations engineers become part of the team. This allows to integrate
the operations tasks like incident management and user support into the team. Similarly, the
testing and monitoring now be fully automated so that the ops engineer can take the
responsibility for the deployments alone. This means that also in terms of responsibility the
DevOps approach Teams become responsible for development, unit testing as well as
acceptance testing and also deployment and release. Meanwhile, monitoring, incident
management, as well as business continuity remain part of the infrastructure and operations
teams.

Finally, the third phase is fully agile where a full integration within the team and the processes is
achieved. Relevant controls and monitoring are fully automated end-to-end so that also the
teams can take full ownership of the deployments. This means that also in terms of responsibility
the DevOps approach Teams become responsible for development, unit testing as well as
acceptance testing, deployment and release, application operations and monitoring, incident
management as well as business continuity management. Only database management, platform
management as well as infrastructure operations and monitoring remain with the respective
infrastructure and operations teams.

The consecutive execution of these phases also leads to a full end-to-end toolchain that
automates the relevant controls. This specifically includes that in a full DevOps approach model,
all software codes should be handled in one repository. Auto inputting software codes into the
repository also ensures that relevant tests and security checks are executed.

Similarly, when there is a need to build building process automation software using related tools
and fully automate additional integration, user and security tests. Finally, actual software
deployment should be an automated process in the relevant toolkit series. Therefore, the full
toolkit series described here is also referred to as the Development and Operation Approach
(DevOps) toolkit series. Verification of the model's adoption in the context of best practices as
part of continuous roll out. There are usually joint verifications in accordance with the principles
of 6-monthly approaches, which in turn further guide the roll out approach.

26
 5.1.6 DevOps Approach Sustainability & Measurement
There are six top-level KPIs, which are typically used in a DevOps approach context to
measure the overall performance of IT.

Top-class Average class Underperforming /

KPI Description
performance performance legacy
Time it takes from "software
code inputted" to
Lead time <1 hour 1 week – 1 month >1 month
"implementation in
production phase"

Frequency of which new

Deployment
increments rolled out to Multiple per day 1/week – 1/month <once/month
frequency
production

In the event of a malfunction,

Mean time taken to
time it takes to restore normal <1 hour <1 day >1 day
recover
operation

Percentage of erroneous
Change Failure Rate 0-15% 15-30% >31%
deployments to production

Share of developers over total

Productive time >80% 50-80% <50%
staff

Employee Net Likelihood of personnel to

Promoter Score recommend their place of >70 40-70 <40
(NPS) work

Table 1 : KPIs to measure performance of IT

These different KPIs as well as the respective benchmarks values listed above are
monitored to ensure the overall performance of a government entity IT while the entire
value stream is monitored to facilitate continuous improvement. This shall be a part of
both reviews within the teams as well as the review process within the DevOps approach
organization every 6 months. It is essential to set up a corresponding governance around
the reviews and the corresponding definition of actions. A standard practice is that the
quality department within the organization can take over the responsibility of conducting
the reviews against the ISO standards and define corrective actions if required.

27
 The operational performance inputs can be gathered from the tools directly whereas for the
further inputs, interviews with the teams are required. Concerning the measurement of input
metrics, the measurement of the required metrics needs to be set up from the tools and
monitoring tools need to be configured. Also, input data as the number of stories and other need
to be gathered from the tooling for sprint planning etc.
This allows monitoring each part of the DevOps approach process previously described including
the number of stories produced by each team, their respective complexity, the time it takes to
build, the errors in production etc. This data can be further leveraged to drive the continuous
improvement process. This excludes the planning process as this one defines several of the
baselines for the metrics described below.

Metrics to measure in a DevOps approach setup:

Create:

• Build-success rate (%): Share of successful (software) builds of code committed in the cost
repository
• Velocity (Number of Points/day): Volume of story points that a team or an individual developer
can deliver per day
• Software Code Quality: Quality of the software code as measured by software code quality
tools

Verify:

• Unit test coverage (%): Percentage of software code inputted that is covered by unit tests
• Build success rate (%): Share of successful (software) builds of software code inputted in the
cost repository
• Security test pass rate (%): Share of inputted software code that passes security checks as
executed by specialized code security tools
• Test success rate (%): Share of tests that are successful for inputted software code

28
 Package/ pre-prod:

Package success rate (%): Share of packages successfully produced

Release:

Deploy success rate (%): Share of deployments that are successful for inputted software code

Configure:

Mean time to restore: Average time it takes for an application to restore normal operations
after a (significant) incident

Monitor:

Incidents per month (per priority): Number of production incidents by priority/severity

The measurement of these metrics and the definition of required corrective measures are
executed by the teams. Additionally, formal reviews following the ISO standard conducted, as
per best practice, every 6 months and presented to the CIO of the government entity to define
and execute corrective measures.

29
 Table of Definition
The following terms and expressions - wherever they appear in this document - shall have the
meanings indicated on the opposite side of each of them, unless the context requires otherwise.

Term Definition

Authority Digital Government Authority

Ministries, authorities, public institutions, councils, national centres including any additional form of a
Government entities
public entity.
Promotes administrative, organizational and operational processes between the various government
Digital Government entities in their transitioning to a comprehensive digital transformation to allow easy and effective access
to government digital information and services.
Citizens, residents, visitors, government agencies, private sector, non-for-profit sector, inside or outside
Beneficiary
the KSA that require to interact with a government entity to receive any of the services offered in the
Kingdom.
DevOps approach is the combination of cultural philosophies, practices, and tools that increases an
organization’s ability to deliver applications and services at high velocity; evolving and improving
DevOps products at a faster pace than organizations using traditional software development and infrastructure
management processes. This speed enables organizations to better serve their customers and compete
more effectively in the market.

Digitally and strategically transforming and developing business standards and models that would rely on
Digital Transformation
data, technologies, and ICT.

Parties and entities that affect and are affected by decisions, directions, procedures, objectives, policies
Stakeholder and initiatives of the digital government and share some of their interests and outputs and are affected by
any change that occurs in them
CI/CD is a method to frequently deliver applications to customers by introducing automation into the
CI/CD stages of app development. The main concepts attributed to CI/CD are continuous integration,
continuous delivery, and continuous deployment.
The waterfall methodology is a project management approach that emphasizes a linear progression from
Waterfall software
beginning to end of a project. This methodology, often used by engineers, is front-loaded to rely on
development
careful planning, detailed documentation, and consecutive execution.
A service-level agreement (SLA) sets the expectations between the service provider and the customer and
Service Level
describes the products or services to be delivered, the single point of contact for end-user problems, and
Agreement (SLA)
the metrics by which the effectiveness of the process is monitored and approved.

Plan Create a plan for how to develop the application/ the service and its further development

Create Develop the actual code

Verify Manage and ensure the quality of the delivered code and further end products

Package/ pre-prod Make the product/ service ready to be deployed

Release Ensure that code can be delivered to production

30
 Term Definition

Configure Configure the application and the underlying infrastructure components

Monitor Monitor the underlying health of application and the hardware usage

Reporting Line Disciplinary reporting line in an organization

Performance Appraisal
Employee performance review process as part of HR performance management
process

Collaboration
Tools within the DevOps approach architecture to facilitate the collaboration between teams
Platforms

PaaS Services Services for providing certain platforms as e.g., pre-configured databases

Infrastructure
Ensuring actual deployment of infrastructure as servers and network for required software services
Provisioning

Portfolio Planning Process to plan IT investments and/or IT projects in an organization.

Servant leadership is a leadership approach built on the belief that the most effective leaders strive to
Servant Leadership serve others, rather than accrue power or take control. The aforementioned others can include customers,
partners, fellow employees, and the community at large.

Agile ceremonies are meetings where a development team comes together to keep each other updated
Agile Ceremonies on their project’s details. At the same time, other Scrum ceremonies, such as the sprint retrospective,
helps the scrum team look back on their work and find ways of improving for future sprints.

Those requirements would include an analysis of the core requirements described with specific use cases
and key metrics that define their success and validate if the technology considered either meets or has
Functional
limited or no use for the functional requirements defined. Additionally, critical functional requirements
Requirements
that need to be considered are the suitability of the ET’s architecture and alignment with the
governmental entity’s current and envisioned architecture in the future.

31
 Table of Abbreviation

Abbreviations Description

CI Continuous Integration

CD Continuous Delivery

E2E End-to-end

SRE Site Reliability Engineering

DevOps Development and operations combined

ISO International Standards Organisation

IEEE Institute of Electrical and Electronics Engineers

NPA Net promoter score

SP Story Point

CIO Chief Information Officer

CI
Continuous Integration

32
DGA.GOV.SA