Every engineer wants to work with the latest and trend technologies, develop and try new things. Businesses are not always ready or willing to innovate their products, so architects must prove that these innovations are absolutely necessary for the business and will solve specific tasks, to solve specific problems or achieve the highest goals, and without these steps it will be very difficult to achieve this. On the other hand, if the business has already decided to implement digital transformation and innovation, then the architects need to have a clear plan and a gradual development path, and it is possible that there will be many stages and several transformations in different industries along the way. architecture (business, data, applications, technologies). In the first and second cases, it is very important first of all to define the goals for each stage and how to measure the system indicators and how well they meet the goals. This talk will present:: What is digital transformation and how to identify exactly which innovations / technological trends are needed; High-level process (from preparation, identification of targets to measurement of quality attributes at various stages); Basic concepts, principles and methods (e.g. quality attributes, fitness functions, architectural design concepts that should be used and development based on hypotheses, etc.); The role of the Architect in this process; The main part of the speech is to present tips and tricks on examples of roadmaps for digital transformation and innovation in the following areas: implementation of DevOps/SRE cultures, development standards and Test Strategy, migration from monolith to the microservices architecture. The main goal of the speech is to show a structured process of digital transformation and implementation of innovation and advice based on examples in the main directions. This talk will be useful to:: architects and technical consultants who are engaged in the development of architectures at various levels (from application to enterprise); technical leads and software developers who are engaged or will be engaged in facilitating the process of implementing innovations and digital transformation; engineers of various fields of Development, DevOps/SRE, Data, QA and other fields; system analysts and engineering managers.

2. Speaker.
winner of Ukrainian IT Awards in category Software
Engineering in 2019, Jury in 2020
14+ years in software design & development
Director, Enterprise Architect
speaker on conferences, meetups, workshops
Led big programs (150+ engineers) and departments
with 300+ engineerings
SEI / TOGAF trained, icAgile Certified
Ukrainian 󰑒, father of 2 beautiful children

3. AGENDA
What is Digital
Transformation?
Common Definitions,
Reasons,
Types
Role of Architect
What should an Architect
focus on during digital
transformation?
Transformation
Roadmap
Preparation,
Execution,
Measurement
Re-Architecture Test Strategy Ops Cultures

4. What is Digital Transformation?

5. What is it digital transformation?

6. When we should do digital transformation?
Business / Product Transformation
(e.g. migration to SaaS)
Region / location expansion
New Business goals (e.g.
time-to-market, number of clients)
Implementation of Complines,
Regulation standards (ISO, GDPR,
HIPAA, etc.)
Business processes optimisation
(e.g. cost, operations)
Integration existing product with new
components,
buying new components
New quality, security, performance
requirements
Digital
Transformation
New most relevant technologies
were introduced and released

7. Types of Digital Transformation.
Digital
Transformation
Cloud Adoption
Test Strategy
Re-Architecture
DevOps/SRE cultures
Delivery/Development standards
Enterprise & Product innovation

8. When you start to think that a transformation is needed.
Time-to-Market
(duration from idea to production, lot of meetings,
hard discussions, etc.)
Engineering challenges
(e.g. Lead Time, Deploy frequency, Time to restore, CI/CD
duration, time for adding new components, etc.)
https://www.devops-research.com/quickcheck.html
Idea Planning &
Development
Production
release

9. When you start to think that a transformation is needed.
The Frozen Caveman
Developer To Architect - Lesson 130
Big Ball of Mud
building evolutionary architectures

10. Transformation Vision. Revolutionary or Evolutionary
Option 1:
Build from scratch
Products
Option 3:
Small wins - Build new
products components
and innovate existing
Products
Products Too disruptive limited
value add in interim
period
Flexible approach with
value over time
Time
Option 2:
Development of 2 products
(new and gradual creation
of new components with
innovations)
Products Products
Products
Solution procrastination
Products
Products

11. What does transformation depend on?
Type of business
(product/service company) &
business domain
Capabilities
Business goals
Way of Transformation
(Evolution of Revolution)
Type of Transformation
(Cloud Adoption, Testing,
Re-Architecture, etc)
Current State
Roadmap
Who will create
transformation

12. Role of Architect.

13. Activities depends on Types of Architects.
● Application Architect
● Solutions Architect
● Systems Architect
● Enterprise Architect
● Business Architect
● Technical Architect
● Integration Architect
● Information Architect
● Security Architect
● Data Architect
● Network Architect
● Cloud Architect

14. 2 types of activities.
When you need present reason -
why we should implement transformation.
When Transformation was confirmed and you
should start preparation for the Transformation.

15. How can you explain the need for transformation?
● Growth of business (e.g. growth of
business domains / functionality /
products, increase number of clients)
● Generate capabilities (enablers):
○ decrease time-to-market
○ expansion
○ fix existing challenges
○ regulations and compliances
○ integrations
● Budgets optimisation, More effective
and efficient business operations
● To be one step ahead of competitors
● Better return on existing investment,
reduced risk for future investment
Operational Excellence
Security
Reliability
Performance Efficiency
Cost Optimisation
Pillars from IT industry Real benefits for Business

16. How can you explain the need for transformation? Examples
Why we should migrate our infrastructure to the Public Cloud (e.g. AWS, Azure, GCP, etc.)?
● Possible answer: With Cloud we will have better supportability, Cloud already has many services and we will
manage this with easiest way.
● Additional answer: With Cloud we will have greater flexibility to scale resources easily, we can easy control and
optimise cost. Cloud will decrease our cost of infrastructure and support to 10-20% and to 30-35% after cloud
innovation.
Why we should migrate from current Architecture (e.g. Service-Based) to new (e.g. Microservices)?
● Possible answer: Microservices is modern approach and lot of companies already moved or in-progress with migration.
With Microservices we can increase of lot of quality attributes (e.g. testability, agility, scalability, etc.).
● Better answer: Microservices will speedup process of development (optimized development time and cost), so we can
add more features quickly and adjust some functional if needed.
Why we should switch from one Test AQA approach to new one?
● Possible answer: with new Test Framework we can run test suites in parallel, so speedup process of execution tests,
and speedup overall CI process, new Framework will include reporting in-box and lot other components.
● Additional answer: new Test Framework will provide flexibility to add more test quickly, speed up process of
acceptance testing, so decrease time-to-market for features of product.

17. What you can use for explanation.

18. What you can use for explanation.

19. Architect Elevator.
● Cloud-ready applications demand run-time architecture
● Automate software manufacturing to reduce time-to-value
● Minimize upfront decision making
● Sell architecture options
● Make architecture fit for purpose
● Validate decisions through feedback loops
● Architect the organization alongside technology evolution
● Remove blockers at the right “floor”
● ArchOps: Build a vertical architecture team
● Keep riding the elevator
Many large organizations see their IT engine separated by many floors from
the executive penthouse, which also separates business and digital strategy
from the vital work of carrying it out. The primary role of an architect is
to ride the elevators between the penthouse and engine room, stopping
wherever is needed to support these digital efforts.
Gregor Hohpe
https://martinfowler.com/articles/architect-elevator.html
https://architectelevator.com/

20. Digital Transformation Roadmap.

21. Common Transformation Roadmap.
Current
State
Target
State
Time
Milestone 1 Milestone N
Discovery
● Vision
● Evaluate current state
● Capabilities
● Risks & Change Management
● Roadmap (milestones, iterations)
● Methods (inc. experiments)
● Architectural Design Concepts
Measurement
● Business objectives
● Quality Attributes
● Fitness Functions
● Automatisation & Operations
● Communication
Iteration 1 Iteration N

22. Discovery.
Assessment
Preparation Results
● Understand business needs and
validate business drivers.
● Doing all actions for covering
enablers for Assessment.
● Minimize blockers for Assessment.
● Collect maximum relevant
information from different sources
using methods that were chosen
during Preparation.
● Prepare final deliverables.
● Presentation.
Analysis
● Identify Target State
● Analyse feasibility for
migration to the Target State.
● Choose concepts (e.g.
technologies, architectural
styles) to achieve targets.
● Create Roadmap.
Discovery Measurement

23. Discovery. Preparation
Common Activities
● Initial information analysis (high-level product
view, objectives, requirements, Initial list of
deliverables).
● Team preparation (methodologies list,
processes overview, trainings).
● Scope, Method selection.
● Creation of list of activities, calendar.
● Preparation for sessions.
● Preparation of infrastructure for assessment.
● Choosing of tool-set for assessment
(checklists, tools, communication tools, etc.).
● Alignment with all stakeholders.
Methods
Toolset
Checklists Calendar Team Infrastructure
Discovery Measurement

24. Discovery. Assessment
Common Activities Methods
Toolset
● Facilitation and leading, monitoring all steps,
checking progress.
● Change / Risk management.
● Checkpoints management.
● Self-Analysis activities (e.g. code analysis,
document analysis, observation (check logs,
monitoring information)).
● Run Automation Tools:
○ Code analysis,
○ Security,
○ Performance.
Sessions Self-Analysis Automation
Tools
● Elicitation methods
● SonarQube
● Cloud Well Architectured Tools
● Monitoring & Logging tools
Discovery Measurement

25. Discovery. Analysis
Common Activities Methods
Toolset
● Identification of New Targets and
measurement methods.
● Identification of new Architectural
principles.
● Choosing of relevant Design Concepts
(Reference Architectures, Deployment
Patterns, Architectural / Design Patterns,
Architectural Tactics, Technologies).
● Check hypotheses.
● Creation of Transformation Roadmap.
● Calculation of Transformations Cost.
● Architectural Design Concepts catalogues:
○ Reference Architectures
○ Architectural Styles/Patterns
○ Architectural Tactics
○ Development Components
○ Modern Technologies
○ Industry Trends
● Quality Attributes, Fitness Functions
● Best Practices (e.g. Well Architectured Frameworks)
● Estimation techniques & tools
● Budget calculators (e.g. Cloud infra calculators)
Hypothesis
Driven Design
Quality Attribute
Workshop
Architecture Design
methods (e.g. ADD)
Discovery Measurement

26. Discovery. Results
Common Activities Methods
Toolset
● Preparation of final deliverables:
○ Software Architectural Documents,
○ Architectural Views,
○ Architectural Decisions.
● Roadmap (e.g. Gantt chart).
● Presentation of final deliverables.
● SEI View & Beyond
● Kruchten’s 4+1 View
● C4 model View
● UML
● ArchiMate
● SysML
● …
● SEI View & Beyond
● 42010
● TOGAF
● ADR
● arch42
● …
Templates
● ArchiMate
● Sparx
● Lucidchart
● Draw.io
● Visio
● Confluence
● …
Tools
Styles / Frameworks /
Models / Language
Discovery Measurement

27. Targets & Measurement. What we can use?
Discovery Measurement

28. User initiate transaction to the System under normal
operation and transaction are processed with average
latency of 2 second.
Targets & Measurement. What we can use?
Discovery Measurement

29. Targets & Measurement. What we can use?
Quality Attributes Scenarios
Quality Attributes Utility Tree
Assessment results,
Industries Standards
Metrics Levels:
● Code quality (% test coverage at each level)
● Incidents
● Quality of Manual Test scripts
● Security
● Delivery Metrics (Quality of the Backlog)
● CI/CD Pipeline
● Monitoring and Alerting
● Technical debt
● …
Architectural Fitness
Functions
Discovery Measurement

30. Targets & Measurement. Architectural Fitness Functions
An architectural fitness function provides an objective integrity assessment of some architectural characteristic(s).
Unit Test Coverage > 0.7;
Execute on each CI Build; Fail when below target coverage.
Integration test errors = 0% (when network latency is 10s for third-party API call);
Execute on each nightly integration test build; Fail when integration test fails.
Fitness Functions Examples:
Discovery Measurement

31. Targets & Measurement. Architectural Fitness Functions
Discovery Measurement

32. Targets & Measurement. Architectural Fitness Functions
Category Possible values
Unit Test Coverage > 0.7;
Execute on each CI Build; Fail when below target coverage.
Breath of feedback Atomic or holistic Atomic - Unit test coverage only gives us limited feedback on
the function of the whole system.
Test execution trigger Triggered or Continuous Triggered
Execution location CI/CD, test environment, production system, etc. CI - Execution is triggered on each push to the source control
system, and will execute the unit tests and measure the unit test
coverage.
Metric type True/False, discrete value, time series/historical
values
a specific value (> 70%)
Automation Automated of manual The fitness function will be evaluated automatically.
Quality attribute Functional suitability, performance efficiency,
compatibility, usability, reliability, security, …
Maintainability - With this fitness function, we pursue the goal
of keeping our system maintainable at certain levels; we treat
good test coverage as an indicator that the system can be
maintained (adapted, changed, improved) more easily.
Discovery Measurement

33. Transformation Roadmap in details. Architectural Fitness Functions
Category Possible values
Deploy the new release to our production system (at night, 01:00 AM).
While the release is rolled out, constantly perform the regression test
set containing the 5 main end user use cases (login, put item to cart,
remove item from cart, view cart, checkout). The system performs all
actions and responds within 100ms.
Fail when test case fails;
Fail when system doesn’t perform actions and respond < 100m
Breath of feedback Atomic or Holistic Holistic - The measure is a direct measurement of the whole system during
deployment, not of all online nodes.
Test execution trigger Triggered or Continuous Triggered
Execution location CI/CD, test environment, production system,
etc.
CI/CD to Production environment
The evaluation of the fitness function is done using a discrete trigger (nightly
at 01:00 AM) in the production environment.
Metric type True/False, discrete value, time
series/historical values
The first type is a discrete value (performance), with verification if the value
is above the threshold.
The second value is 0/1: the system is available during deployments, and
tests don’t fail.
Automation Automated of manual Automated. The fitness function will be evaluated automatically.
Quality attribute Functional suitability, performance efficiency,
compatibility, usability, reliability, security, …
Includes reliability and performance efficiency.
Static or Dynamic Static or Dynamic Static - This fitness function would be in the pyramid’s top layer.

34. Targets & Measurement. Architectural Fitness Functions
Pseudocode as overview
Discovery Measurement

35. Architect’s Focuses.
Current State Identification Goals & Targets
Transformation strategy & Roadmap Technologies & Design Methods

36. Re-Architecture.

37. Key topics for transformation during Re-Architecture.
Software Development
Components
Development
Practices
Development
Infrastructure
Governance, Team Composition,
Change Management
Infrastructure
Testing
Strategy
Release &
Support
Data
Governance

38. Re-Architecture / Enterprise Transformation.
Product
Develop the governance and culture/ways of working which empowers product teams to
take ownership and drive the transformation.
Delivery
Build a modern delivery skillset and drive new ways of working to provide the flexibility
the transformation requires.
Leadership &
Governance
Align the Leadership structure, KPIS and Governance methodology to provide clear
guidance to business teams.
Engineering
Define the engineering principles, methods, toolkits and ways of working to enable
evolution whilst still providing engineering flexibility.
Architecture
Establish the architectural foundations and governance model to underpin the
transformation.

39. Re-Architecture.
Phase 1
Quick Wins
Proactive Standardisation
Phase 2
Measurement & Control
Phase 3
Continuous Optimisation
Product
Establish the current Product Approach,
Ways of working and governance structures
Embed the Product approach across one
specific value stream to prove value
Showcase outcomes and initiate
widespread adoption across remaining
value streams
Engineering
Establish Development Standards and Strategies
for cross-functional teams to support
Component-Based development
Implementation of PoC/Prototypes,
enablers for Continuous Delivery,
development practices to support work
with shared and splitted components
Integration of automation at all levels
and continuous delivery practices
Architecture
Architectural Governance and Standards
implementation, Integration of Architectural
Design Concepts & Principles for migration to
Microservices
Growth of Microservices ecosystem and
interactions between components with
focus on security, testability,
deployability, availability and
performance
Architecture and Infrastructure
optimisation to achieve targets
architectural characteristics / quality
attributes
Delivery
Lean Canvas, Cloud Migration Readiness
Assessment, Organisational Readiness
Assessment. Prioritisation of services & Risk
Assessment.
Squad and Core Team delivery mindset,
Chapter Leads, Delivery Metrics,
Feature-Teams,
Delivery Metrics monitoring
Empowered teams, clear roadmaps,
established feedback loops, test & learn
culture, CI/CD by design
Leadership &
Governance
Set Vision & clear objectives, RACI, Stakeholder
Mapping, Escalation Process, Document Decision
making process, Identify change management &
communication strategy and identify metrics.
Embed the governance processes,
measure effectiveness and make relevant
adjustments. Iterate comms approach to
align to impact across domains.
Continuous validation and iteration of
governance processes and comms
approach to ensure effectiveness.
Evolution of KPI’s as teams mature.
Time

40. Re-Architecture. Example of Engineering Roadmap
Phase 1
Proactive Standardisation
Phase 2
Measurement & Control
Phase 3
Continuous Optimisation
Solutions
- Development Standards (e.g. Toolset, code
conventions & styles, API documentation,
Cross-Stack contracts, code review, etc.)
- Development Infrastructure (Code repositories
structure, branching / versioning strategies)
- 12 Factors app mindset
- Docker on all stages
- Build out the DevOps culture
- Test Strategy (e.g. levels, code coverage strategy)
- Shared / 3rd party components management
- CI / CD strategy
- Cloud Adoption / Innovation approaches
Outcomes
Each delivery team member knows and
uses the same development standards
and processes for interacting with other
team members.
Solutions
- None-Breaking Change Development
- GitOps, IaC & CI/CD improvements
- Orchestration (Kubernetes)
- Monitoring & Logging strategies
- Continuous inspection of code quality
- Automation of Quality Monitoring
Outcomes
All developers can work together without
blocking the work of other teams &
engineers. Engineering metrics are fully
monitored and analysed to forecast quality
and implementation of improvements.
Solutions
- Continuous Delivery
- Quality Gates for CI
- Cost Optimisation
- Regression Testing & Release plan
- Post-Release Support
- SRE strategy
Outcomes
Maximum delivery performance without
any blockers. Release cycle is fully
automated and optimised. Post-release
support is easy and understandable
within the organisation.

41. Re-Architecture. Example of Architecture Roadmap
Phase 1
Proactive Standardisation
Phase 2
Measurement & Control
Phase 3
Continuous Optimisation
Solutions
- Architectural Governance & Standards (ARB,
ADRs, RFCs, Architectural principles)
- Quality Attributes, Fitness Functions
- Component-Based/Modular Architecture
- Cross-Stack contracts
- Architectural Design Concepts as enablers for
transformation (e.g. Service-Based Architecture,
Microservice Chassis, Strangler Fig pattern,
Micro-Frontend, etc.)
Outcomes
Agility & Organizational Flexibility.
Solutions
- Domain Driven Design
- DB per Service
- Event-Driven Design
- Micro Front-End
- Security design principles on all levels
- Hypothesis Driven Development
- Fitness Functions strategy
Outcomes
Cross-functional teams can develop,
test, deploy, and update services
independently, which leads to faster
overall delivery.
Solutions
- Microservices with Different Types of Service
- Business Distributed Transactions support
- Performance (Scaling Cube implementation)
- Availability (Load Balancer Cluster integration)
- Reliability Cluster
Outcomes
All quality attributes are monitored and
analysed for approximation to targets.
Easy Supportability, Updatability,
Scalability.

42. Re-Architecture. Transformation Strategy
Component-based decomposition
patterns (flow and usage)
Software Architecture: the Hard parts (page 83)
1. “Identify and Size Components Pattern”
2. “Gather Common Domain Components Pattern”
3. “Flatten Components Pattern”
4. “Determine Component Dependencies Pattern”
5. “Create Component Domains Pattern”
6. “Create Domain Services Pattern”

43. Re-Architecture. Current State & Targets

44. Re-Architecture. Current State & Targets
Software Architecture: the Hard parts (page 83)

45. Re-Architecture. Current State & Targets
Software Architecture: the Hard parts (page 117)

46. Re-Architecture. Technologies & Design methods
Performance, security,... patterns Architectural Tactics
Reference Architectures
Architectural styles and patterns Technologies

47. Re-Architecture. Technologies & Design methods
User only notices improvements in performance, security, accessibility, etc., without any changes to the current user experience.
Platform
Frontend
Early State Future Stage
Modernized Application
Strangler facade
Frontend
Strangler facade
Create a facade that
intercepts requests going to
the backend legacy system.
The facade routes these
requests either to the legacy
application or the new
services.
Over time, as features are
migrated to the new system,
the legacy system is
eventually "strangled" and is
no longer necessary. Once this
process is complete, the
legacy system can safely be
retired.
Existing features can be
migrated to the new system
gradually, and consumers can
continue using the same
interface, unaware that any
migration has taken place.
On the future stage, the API
gateway (facade) centralizes
security and cross-cutting
concerns such as externalized
configuration, logging, health
checks, metrics, service
registration and discovery,
circuit breakers

48. Re-Architecture. Technologies & Design methods
Process (Mono -> Macro -> Micro)
1. Modules/plugins inside the monolith
2. Common services / Macroservices
3. Service Based architecture (increasing the
number of services and splitting the Database)
4. From Macroservices to Microservices
What are you can solve with this approach?
● Evolution / not Revolution
● Small wins at all stages
● Agility & Organizational Flexibility
● Fully controlled & monitored Security,
Performance, Testability, Deployability
● Easy Supportability, Updatability, Scalability, etc.

49. Test Strategy.

50. Test Strategy Transformation.
● Test Approach
● Test Actors
● Types of Tests
● Test Planning and Execution
● Entry and Exit Criterias
● Test Data Management
● Test Environments
● Release Control
● Test Automation
● Test Tools
● Risk Analysis
● Test Change Management
● Collaboration strategy
● Functional Testing
● Non-Functional Testing
Test Strategy
Key topics for improvements
Transformation Examples
● Overall Test Strategy Transformation (new QA
approach based on reorganisation)
● Migration from one Test Approach to new one:
○ From Test Tool to Framework (SoapUI
to RestAssured)
○ BDD / TDD implementation
● Implementation of new Types of tests
● Post-release / Production testing
● Test improvements to support Re-Architecture
● New Quality attributes (e.g. performance,
security, availability, etc.)

51. Test Strategy Transformation. Methodologies
Architectural Fitness Functions
Integration test errors = 0% (when network latency is 10s for third-party API call);
Execute on each nightly integration test build; Fail when integration test fails.

52. How you can define Targets?
Functional
Testing
Unit Testing
Integration Testing
System Testing
Acceptance Testing
Non-Functional
Testing
Performance Testing
Security Testing
Usability Testing
Compatibility Testing
Software
Testing Measuring QA metrics needs to take place at every phase of the delivery,
with actions being taken promptly to resolve problems.
General Metrics:
- Reopened Stories Ratio
- Reopened Bugs Ratio
Accumulated Ratio:
- Project Bug Index
- Bugs Per Story
- Time Lost for Bugs
Current Bugs Status:
- Opened bugs
- Opened Blocker and Critical Bugs
- Not-assigned Opened Critical and
Blocker Bugs
Current Bugs Details:
- Absolute Numbers of All Opened
Bugs
- Detailed Statistics for All Opened
Bugs
Requirement Quality:
- Bugs in Requirements
- Test Coverage of Requirements
Sprint Metrics:
- Sprint Velocity
- Sprint Burndown
- Actual Stories Completed vs.
Committed Stories
- # of Created Test Cases
- # of Automated Test Cases
- # of Executed Test Cases with
Statuses
- Test Cases Dept
- # of Logged/Fixed Critical/Major
Defects
- Defects Fix Rate
- Estimation Accuracy
- Ratio of Successful Sprints

53. Test Strategy Transformation. TestOps Culture
Development
Test
TestOps DevOps
Operations
SDET
● Test Planning
● Test Case Design
● Test Execution and Analysis
● Testing & Retesting
Architectural Quality
● Scalability analysis
● Performance testing
● Reliability Testing
● Maintainability
Configuration Quality
● Unit Test Configuration
● Equivalence Testing
● Rollback Testing
Early Monitoring
● Unit Test Monitoring Configs
● Performance Testing

54. Test Strategy Transformation. Technologies & Methods
● Chaos Mesh
● Gremlin
● Litmus
● ChaosBlade
● Pumba
● ChaosKube
● Simmy
● Pystol
● Chaos Toolkit (ctk)
● Netflix Chaos Monkey
Chaos Testing

55. Test Strategy Transformation. Technologies & Methods
https://github.com/OWASP/owasp-mastg
Security Check Tools
Code scanning
● SonarQube
● WhiteSource
● VERACODE DAST scan
● …
Artifacts scanning
● Docker Content Trust (DCT)
● Twistlock
● AquaSec
● Qualys Cloud Platform
● …
Testing Approaches and Methods

56. Ops Cultures.

57. Ops Cultures Transformation.
Reasons for Transformation
● Ops cultures implementation
● Infrastructure innovation and/or optimisation
● Cloud Migration & Innovation (6R’s of AWS:
1.Rehosting, 2.Replatforming, 3.Repurchasing,
4.Re-architecting, 5.Retire, 6.Retain)
Key points for transformation
● CI / CD, Continuous Delivery (3C approach)
● Branching & Versioning strategy
● Release lifecycle
● Security
● Dockerization & Orchestration
● Scaling (e.g. auto, manual)
● Monitoring, Logging, Tracing strategies
● Operational Governance (inc. change management)
● Production support (e.g. incident management)
● Disaster Recovery Approach
● …
Methods to define Current State and Targets
Operational
Excellence
Security Reliability Performance
Efficiency
Cost
Optimisation

58. Ops Cultures Transformation. Current State & Targets

59. Ops Cultures Transformation. Current State & Targets
AWS Well Architectured Tool
Azure Well-Architectured Review
GCP DORA DevOps Quick Check

60. Ops Cultures Transformation. DevOps and more…
Ops cultures:
● ITOps / TecOps
● DevOps
● SecOps
● DataOps
● GitOps
● AIOps
● ChatOps
● FinOps
● NoOps
IT
operations
DevOps
Development Quality
Assurance

61. Ops Cultures Transformation. FinOps & NoOps
DevOps
NoOps
ITOps AIOps
Benefits:
Maximized Development Time
No Manual intervention
Full Cloud Capacity
Challenges:
Increased Workload
Increased Security
Lack of Compatibility
Engineering/Ops/Infrastructure
Business/Product Owner
Executive
Finance/Procurement
FinOps
Rate Negotiations
Infrastructure Change

62. How you can choose technologies stack?
https://digital.ai/periodic-table-of-devops-tools

63. How you can choose technologies stack?
https://github.com/cncf/landscape

64. How you can choose technologies stack?
https://github.com/cncf/landscape

65. Roadmap example for DevOps Innovations.
DI-1 DI-2 DI-3 DI-4 DI-5 DI-6 DI-7
Reference
Jenkins Job
DevOps
Governance
improvements
Jenkins infra
improvements (e.g.
runners, cache)
Terraform Refactoring
CI for Mobile
platforms
Dashboards
Automatic
release notes
Jenkins
configuration
as code
Jenkins reference
Job for all
components
Branching &
Versioning Strategy
DB Management
automatization
CI Release
Provisioning
Job
SonarQube advanced
integration
(incl. security checks)
CI observability /
Reports
Docker
Implementation
K8s
Implementation
Docker for
CI
Feature
Environments
GitOps for
K8s
Helm Chart
Monitoring, Logging
Security
Improvements
Cost
Optimization
Tracing for
applications
Disaster
Recovery
Approach
Change
Management
Terraform Advanced
Configuration
CI QA process
automatization
Mobile tests

66. Useful Materials.

67. Books.

68. Useful Methodologies.

69. Useful Methodologies.
What is Digital Transformation?
What is Digital Transformation?
What is Digital Transformation?
Azure Digital Transformation
Digital Transformation

70. Thank you.
Oleksandr Savchenko
Email: dev.olsav@gmail.com
LinkedIn: https://www.linkedin.com/in/oleksandr-savchenko-38a28532/