This time – no such thing as long introduction. We will just skip to a discussion with ChatGPT! We are going to discuss DevOps Platforms, their structure, components, approach. And we will check if ChatGPT will replace Technology Consultants like me!

In this article, you will find:

What is DevOps Platform, and why toolset is not enough to have one?
What is DevOps Operating Model?
How to detect, that there is an issue with the model we are having? And how correct one can solve it.
Case-Study on detecting Operating Model issues: me vs ChatGPT.
Is ChatGPT able to replace Technology Consultants like me?

When I’ve started to write this post, I’ve noticed that ChatGPT is providing a lot of buzz-words and concepts mixed with actual answer to my question. Since I am totally new with ChatGPT usage (we are all new at this point), I’m going to ask ChatGPT to short summary of our discussion at the end of each chapter.

What is DevOps Platform?

We will start with the question asked in the title of the post. What we will try to establish from the discussion with ChatGPT:

Are the tools enough to say we have a DevOps Platform? What else do we need?
How Tools & Processes correspond to Organization Structure & Vision?
What elements needs to be placed in DevOps Platform?

Click here to see full discussion with ChatGPT, with my comments to answers and questions

Question	ChatGPT answer	Krzysztof’s comment
Are integrated DevOps Tools enough to have DevOps Platform?	Integrated DevOps tools can certainly be a key component of a DevOps platform, but they are not the only requirement. A DevOps platform is a set of tools, processes, and cultural values that enable an organization to effectively develop, test, and deploy software at high velocity. In addition to integrated DevOps tools, a DevOps platform may also include: 1. Version control systems for managing and tracking code changes 2. Continuous integration and delivery (CI/CD) tools for automating the build, test, and deployment process 3. Monitoring and logging tools for tracking the performance and stability of applications in production 4. Collaboration tools for facilitating communication and collaboration between developers, operations staff, and other stakeholders To be effective, a DevOps platform must be tailored to the specific needs and workflow of the organization, and it must be embraced and supported by all members of the team.	ChatGPT is right about Platforms being much more than just a toolset – and underlined processes and cultural values as enablers for software delivery, which must me shaped for organisational need. So we are going to ask how to shape it. ChatGPT underlined some Platform Capacities – but definitely not all. So we are going to ask about other capacities as well. My answer to this question – a DevOps Platform Business Canvas – you can find here.
You mentioned that DevOps Platform must be tailored to the workflow of the organization. What factors should we consider designing DevOps Platform?	There are many factors that you should consider when designing a DevOps platform for your organization. Some key considerations include: 1. The size and complexity of your organization: A small startup may have very different needs than a large enterprise with hundreds of developers and multiple lines of business. 2. The technologies you are using: Different technologies may require different tools or approaches. For example, an organization that primarily develops web applications may have different needs than one that develops mobile apps or IoT devices. 3. The goals and objectives of your organization: What are you trying to achieve with your DevOps platform? Do you want to increase the speed and frequency of deployments? Improve collaboration and communication between teams? Increase the stability and reliability of your applications? Understanding your goals will help you choose the right tools and processes for your platform. 4. The cultural values and practices of your organization: A DevOps platform is not just a set of tools, it is also a set of cultural values and practices that encourage collaboration, automation, and continuous improvement. To be effective, your DevOps platform must be aligned with the values and practices of your organization. 5. The existing workflow and processes of your organization: You should try to build on and enhance existing processes rather than starting from scratch. This will help ensure that your DevOps platform is adopted and embraced by your team. By considering these factors, you can design a DevOps platform that is tailored to the specific needs and goals of your organization, and that will help you deliver high-quality software at high velocity.	ChatGPT provided a correct answer about factors for Technology & Operating Model selection – but without any examples on decisions to be made. So we are going to ask about that. And we won’t mention Operating Model now – maybe it will pop up later in the answers 🙂
Can you provide some example of DevOps Platform for large enterprise?	Sure! Here is an example of a DevOps platform for a large enterprise: 1. Version control: The organization uses Git for version control, with a central repository hosted on GitHub Enterprise. 2. Continuous integration: The organization uses Jenkins for continuous integration, with builds triggered automatically whenever code is pushed to the repository. Jenkins is configured to run unit tests, static code analysis, and other checks as part of the build process. 3. Continuous delivery: The organization uses a combination of tools for continuous delivery, including Spinnaker for releasing code to staging and production environments, and Terraform for managing infrastructure as code. 4. Monitoring and logging: The organization uses a combination of tools for monitoring and logging, including Datadog for real-time application monitoring, Splunk for log analysis, and PagerDuty for incident management. 5. Collaboration: The organization uses Slack for real-time communication and collaboration, and JIRA for issue tracking and project management. This is just one example, and the specific tools and processes used will depend on the needs and goals of the organization. The key is to have a set of integrated tools and processes that work together to enable the organization to develop, test, and deploy software at high velocity.	The answer is actually partially complete – it focuses mostly on tech part, but barely mentioned the processes part. So we are going to dig into it a little bit.
What are those processes?	There are many processes that can be included in a DevOps platform, depending on the needs and goals of the organization. Some common processes that may be included in a DevOps platform include: 1. Continuous integration: This process involves automatically building and testing code changes every time they are committed to the repository. This helps ensure that code changes can be safely integrated and deployed to production. 2. Continuous delivery: This process involves automating the build, test, and deployment process, so that code changes can be quickly and safely delivered to production. This may involve deploying code changes to staging environments for further testing, and then promoting them to production when they are ready. 3. Continuous deployment: This process takes continuous delivery a step further, by automatically deploying all code changes to production as soon as they are committed to the repository (assuming they pass all tests and checks). This can help increase the frequency and speed of deployments. 4. Incident management: This process involves responding to and addressing issues and failures that occur in production. This may involve identifying the root cause of the issue, rolling back code changes, and implementing fixes. 5. Performance monitoring: This process involves monitoring the performance and stability of applications in production, and taking proactive measures to address any issues that are identified. 6. Security: This process involves implementing measures to ensure the security and compliance of applications, both during development and in production. 7. Collaboration: This process involves fostering communication and collaboration between developers, operations staff, and other stakeholders. This may involve using tools like Slack and JIRA to facilitate communication and collaboration. These are just a few examples of the types of processes that may be included in a DevOps platform. The specific processes will depend on the needs and goals of the organization.	All processes are underlined correctly. So we are going to ask about the actors now.
Who should run those processes? Who should maintain the tools?	In a DevOps culture, everyone on the team is responsible for running and maintaining the processes and tools that are part of the DevOps platform. This includes developers, operations staff, and other stakeholders. In a traditional IT organization, processes and tools are often siloed and the responsibility of specific teams. In a DevOps organization, there is a greater emphasis on collaboration and cross-functional teamwork, and everyone is expected to contribute to and support the DevOps platform. That being said, it is still important to have some level of specialization and expertise within the team. Some team members may have a deeper understanding of certain tools or processes, and they may take on a more active role in maintaining and improving them. However, the goal is to have a shared responsibility for the DevOps platform, and to have all team members contribute to and support it.	ChatGPT actually mentioned DevOps Operating Model without calling it DevOps Operating Model. Important part of the answer, rephrasing it a bit, is that DevOps Platform are Tools & Processes combined and tailor-made for specific organisational culture. And this is what DevOps Operating Model is about.

Here is a summary of our discussion:

A DevOps platform is a set of tools, processes, and cultural values that enable an organization to effectively develop, test, and deploy software at high velocity.
A DevOps platform may include version control systems, CI/CD tools, monitoring and logging tools, and collaboration tools.
When designing a DevOps platform, you should consider the size and complexity of your organization, the technologies you are using, the goals and objectives of your organization, the cultural values and practices of your organization, and the existing workflow and processes of your organization.
Some common processes that may be included in a DevOps platform include continuous integration, continuous delivery, continuous deployment, incident management, performance monitoring, security, and collaboration.
In a DevOps culture, everyone on the team is responsible for running and maintaining the processes and tools that are part of the DevOps platform. Some team members may have a deeper understanding of certain tools or processes, and they may take on a more active role in maintaining and improving them. However, the goal is to have a shared responsibility for the DevOps platform, and to have all team members contribute to and support it.

I perceive DevOps Platform Components and Elements similar to what ChatGPT provided, categorising these with three areas – where Toolset is just one of them. Here they are:

Technology: DevOps Platform requires integrated technologies to realise automated & safe application deployment and operations. As ChatGPT mentioned, those are version control systems, CI/CD tools, monitoring and logging tools, and collaboration tools – but also security, test automation, database servers, networking components, streaming capabilities and quality checks. However, the selection of the technology should be driven by Operating Model & DevOps Team know-how.
Operating Model: DevOps Platform requires a design of processes & responsibilities – both from communication and components ownership. This needs to be tailor-made based on company IT Strategy, size & goals, delivery practices, risk appetite, culture & structure in order to make Platform Technologies a booster instead of showstopper. Operating Model describes who is responsible for what, what services is being provided by DevOps (and other) Teams, how and when.
Team(s): DevOps Platform, in order to be implemented and real (and not something theoretical) needs to be built and operated by committed professionals. It requires strong, customer-oriented focus. DevOps Platform Customer is Application Delivery & Support Team – and their needs are a center of DevOps Platform interest (not technology! Tech is just a tool to provide Application Teams with services speeding-up and securing Application Delivery Processes. How to achieve it from the very beginning, I’ve underlined here).

DevOps Operating Model: Design & Implementation

Here I’ve started a new discussion with ChatGPT – just to focus on DevOps Operating Model specifically. What we will try to establish from the discussion with ChatGPT:

What elements are part of DevOps Operating Model? What types of models can we have?
Why DevOps Operating Model is so important?
How specific model influence technology selection & boundaries?

Click here to see full discussion, with my comments to answers and questions

Question	ChatGPT answer	Krzysztof’s comment
What is DevOps Operating Model?	DevOps is a software engineering culture and practice that aims to bridge the gap between development and operations. It emphasizes collaboration and communication between software developers and IT operations professionals throughout the software development life cycle. The goal of DevOps is to increase efficiency, reduce errors, and accelerate the delivery of software applications. The DevOps operating model involves the use of automation and tools to streamline the software development process, from writing and testing code to deploying and managing applications in production. This includes practices such as continuous integration, continuous delivery, and infrastructure as code. By automating many of the tasks involved in software development and deployment, teams can work more efficiently and make changes to their applications more quickly. In summary, the DevOps operating model is a culture and set of practices that aim to improve the collaboration and communication between software developers and IT operations professionals, with a focus on increasing efficiency and accelerating the delivery of software applications.	Generally speaking – I agree with the answer. What I think is missing is some list of elements which Operating Model should have – so I’m going to ask for that.
What elements DevOps Operating Model have?	There are several key elements that are typically included in a DevOps operating model: 1. Collaboration and communication: DevOps emphasizes collaboration and communication between software developers and IT operations professionals. This includes regular meetings and communication channels, such as chat rooms or forums, to facilitate the exchange of ideas and information. 2. Continuous integration and delivery: DevOps practices often include continuous integration and continuous delivery (CI/CD) pipelines, which allow teams to automatically build, test, and deploy code changes. This helps teams to identify and fix problems early in the development process, and to deploy code changes more quickly and reliably. 3. Automation: Automation is a key element of the DevOps operating model. Teams use automation tools to streamline the software development process, including testing, deployment, and infrastructure management. This allows them to work more efficiently and make changes to their applications more quickly. 4. Infrastructure as code: DevOps teams often use infrastructure as code (IaC) practices, which involve defining and managing infrastructure as code rather than manually configuring physical servers or virtual machines. This helps teams to automate the provisioning and management of their infrastructure, and makes it easier to replicate environments and roll back changes if necessary. 5. Monitoring and observability: DevOps teams use monitoring and observability tools to track the performance and reliability of their applications in production. This includes tools for logging, monitoring, and alerting, which help teams to identify and fix problems quickly. 6. Culture: Finally, the DevOps operating model includes a culture of continuous learning and improvement. Teams are encouraged to regularly review and optimize their processes, and to embrace a culture of experimentation and innovation.	Those topics mentioned by ChatGPT are ones to be addressed by Operating Model elements – but in my opinion, not elements of the model itself. So I’ll rephrase the question into “What are components od DevOps Operating Model“?
What are components od DevOps Operating Model?	There are several key components that are typically included in a DevOps operating model: 1. Version control systems: DevOps teams use version control systems, such as Git, to track and manage code changes. This helps teams to collaborate on code development, and makes it easier to roll back changes if necessary. 2. Continuous integration (CI) tools: Continuous integration (CI) tools, such as Jenkins, help teams to automatically build, test, and validate code changes. This allows teams to identify and fix problems early in the development process, and to deploy code changes more quickly and reliably. 3. Continuous delivery (CD) tools: Continuous delivery (CD) tools, such as Spinnaker, help teams to automate the deployment of code changes to production environments. This helps teams to deploy code changes more quickly and reliably, and to make changes to their applications more frequently. 4. Configuration management tools: Configuration management tools, such as Ansible, help teams to automate the provisioning and management of their infrastructure. This includes tools for configuring and managing servers, networks, and other infrastructure components. 5. Containerization tools: Containerization tools, such as Docker, allow teams to package their applications and dependencies into lightweight containers, which can be easily deployed and run on any infrastructure. 6. Monitoring and observability tools: DevOps teams use monitoring and observability tools, such as New Relic, to track the performance and reliability of their applications in production. This includes tools for logging, monitoring, and alerting, which help teams to identify and fix problems quickly. 7. Collaboration and communication tools: DevOps teams use collaboration and communication tools, such as Slack or Microsoft Teams, to facilitate communication and collaboration between team members. This includes tools for chat, video conferencing, and project management.	Well… those are technical capabilities of DevOps Platform, not Operating Model Components. Unfortunately, this is not just a wording or misunderstanding of terms. If I was a CTO who is fully trusting ChatGPT answers, I would think that deployment of toolset + introduction of DevOps Guild is enough to have a DevOps Platform. It is not. We need also to establish some rules of engagements about those tools – and methods of communication. Without it, the tools will either be too restricted to be used (only DevOpses with power to do anything, blocking the Delivery Teams) – or have a huge entry threshold for those Delivery Teams if we give them admin to everything. Depending on the toolset, team structures, goals of the organization and know-how of the teams – for each capability mentioned in first ChatGPT answer we need to decide, who is responsible for toolset delivery & operations, what roles and permissions needs to be created, how many instances of each tool do we need to deploy, which technology suits us – and how are we going to collaborate around it between teams. This is Operating Model. So in short, Operating Model Components are: 1. Technology Boundaries, Roles & Permissions Matrix – for Teams who are about to build and use DevOps Platform 2. Communication Patterns & Services – rules of engagement for requesting standarized services between Teams 3. Responsibilities & Ownership – who builds and maintains Platform Components Out of those Components, there should be customer (delivery team) – oriented processes established. And hopefully – some SLOs 🙂 I will give ChatGPT a chance to provide better answer to more specific question: who should operate DevOps Tools?
Who should operate DevOps Tools?	In a DevOps operating model, the responsibility for operating DevOps tools is typically shared between software developers and IT operations professionals. Software developers are responsible for writing and testing code, and for using DevOps tools to automate the build, test, and deployment process. They may also be responsible for configuring and maintaining the infrastructure required to run their applications, using tools such as configuration management and containerization. IT operations professionals, on the other hand, are responsible for managing the underlying infrastructure that supports the applications, including servers, networks, and storage. They may also be responsible for monitoring and maintaining the performance and reliability of the applications in production, using tools such as monitoring and observability tools. Overall, the goal of the DevOps operating model is to bridge the gap between development and operations, and to encourage collaboration and communication between these two teams. By working together, software developers and IT operations professionals can more effectively deliver software applications and services to their customers.	ChatGPT provided a right answer to overall IT Operating Model. Generally speaking, IT can be organized in tho ways: as DevOps Model where Devs and Ops are working in one team; and traditional IT, where Devs and Ops are separate units. Of course between those ways there is a full spectrum of configurations, which are not part of this blog post. But what we asked is “who should operate DevOps Tools”. We received a partial answer – ChatGPT suggest that sometimes those tools can be operated by Developers or IT Operations specialists. And it can be true – if organization is mature enough to have such know-how in each Delivery Team… which is not that common 🙂

Here is a summary of our discussion:

DevOps is a software engineering culture and practice that aims to bridge the gap between development and operations. It emphasizes collaboration and communication between software developers and IT operations professionals, and uses automation and tools to streamline the software development process.
The DevOps operating model includes several key elements, such as continuous integration and delivery, automation, infrastructure as code, monitoring and observability, and a culture of continuous learning and improvement.
There are several key components that are typically included in a DevOps operating model, such as version control systems, continuous integration and delivery tools, configuration management tools, containerization tools, monitoring and observability tools, and collaboration and communication tools.
In a DevOps operating model, the responsibility for operating DevOps tools is typically shared between software developers and IT operations professionals. It is generally recommended that these two groups work together as a single team, although this may not be possible in all cases.

ChatGPT correctly addressed topics, which should be considered within Operating model (such as version control, continuous integration, configuration management, monitoring or logging capabilities) – but ChatGPT did not underlined a key answers which Operating Model provides: who is responsible for what? how do we utilise DevOps Capabilities?

Based on a discussion with ChatGPT, IT Director/CTO may have a feeling that toolset implementation plus DevOps Guild is enough to have a smooth DevOps Operations. Which is not that simple – because responsibilities and communication also needs to be designed.

In general – we can have three general directions on building Operating Models:

CloudOps Approach assumes, that we have a Cloud/Admin Team responsible for Cloud Accounts & Access Management – and on-prem infrastructure (for example, up to Virtual Machines). But it is Business Applications (or Product Teams) responsible for setting up Clusters, Observability Toolset, CI/CD, Secret Management etc. This model fits to an organization with mature Business Application Teams, which will not spend much time on setting up both Environment and Business Apps. Or for organizations which have all those capabilities incorporated into monoliths which are operated by those Business App Team.
Shared Responsibility Approach assumes, that all technical tools for application delivery & operations are designed, built and operated by DevOps Platform Team – and provided to Business Applications Teams. Business Application Teams in this model are users of the tools and responsible for all application-specific pipelines, dashboards or alerts setup. And of course – they are responsible for Business Application maintenance, while DevOps Platform Team is responsible for Running Environment, Deployment Tools & Operational Tools maintenance. This model I’ve seen within organizations, which are introducing Microservices and are too busy with Business Delivery to have a space in each Team to set-up own DevOps Toolset.
DevOps Approach assumes, that everything is being delivered and operated by independent DevOps Team – both toolset and business application. This model is a good fit for Product Organizations, where delivered Software is the Business itself; or for organizations mature enough not to over-engineer their delivery.

Naturally, Operating Models are in scale between those three types – because each one requires detailed responsibility boundaries for tools and practices. And this influences the technology selection, and it’s setup. This is why DevOps Operating Model needs to be designed carefully and the reason why it is so important.

This time, I am not satisfied with ChatGPT answers. I was not able to get Operating Model elements and their influence on technology. What’s more, some answers can be misleading, and actually cause situations which I’ve underlined in next chapter.

What happens, when we have just DevOps Tools – but we skip Operating Model design?

Can we just skip designing Operating Model, and set-up Kubernetes Cluster? This is real work! Not just academic excel with responsibilities, roles, permissions and processes. Blah! Well… we can 🙂 but we are about to end-up in one (or all of those) situations. In each one we have all possible DevOps Tech – and yet there are troubles. Let me know which ones you have seen in your organization – because I’ve seen all of them. And many more.

A Bustle

A distribution of toolset between multiple teams, without services of their access & capabilities provisioning ends up in a bustle. I’ve experienced such onboarding many times setting up a new Team, or organising an environment for existing one to deliver some new application.

Situation like that is one of the indicators that there is no Operating Model in the Company (or there is, but a corrupt one). If you need to ask multiple teams for reusable resources and toolset you need for your delivery – and you don’t have one place to ask all of that (some teams are on Slack, others are on Teams – others requires Jira Ticket) – or you need to know specific people in the organization, well… you loose a lot of money on teams downtime, which Operating Model can save you. Because with implemented Operating Model and Capability Delivery Processes, all of this should be obtained in one day maximum. If you need to wait longer, it’s a sign your Company need some work on Operating Model.

A Cognitive Load

This situation happens where there are no DevOps Platform Team Services defined within Operating Model – or the services are not compatible with Application Teams maturity level. Teams are having a technical Cognitive Load in order to consume the outcomes provided by DevOps Team – either because of lack of skill, or lack of time to handle toolset by themselves.

I’ve experienced such scenarios multiple times – and they had one factor in common. DevOps Team were focused on Technology, not on DevOps Capabilities. This resulted in no Services definition, no SLOs, no feedback gathering from Application Teams which were left without support.

The most important factor shaping Operating Model are the real Application Team needs and maturity level (and willingness to take over some responsibility around technical capabilities). An Operating Model not fitting Organizational Culture will became a bottleneck. In a comic on the right DevOps Team is not willing to take responsibility for environments, focusing only on shared code-base for a Platform. A Platform, which Delivery Team may not be able to understand, run and maintain on production.

A Shadow-IT Enabler

This situation as actually an opposite to the Cognitive Load. We have the toolset on one DevOps Team hands, but there are missing roles, permissions and processes to customise anything – or tools do not have technical possibility to give more power into mature Application Team hands.

This situation (in my opinion) may be even more dangerous than the Cognitive Load one – because after some time we are going to have a Shadow-IT, with duplicating DevOps Tools in Enterprise Architecture Portfolio. While a justified duplication is not an issue (and can be a part of IT Strategy), an unplanned duplication of every DevOps capability requires time & money to maintain and operate complementary technology. And some problems with hiring new engineers – or even worse, with staff turnover. This is an indicator, that Operating Model Services are not working as planned.

Final test for ChatGPT – problem diagnosis!

Ok, now we know what DevOps Operating Model is – and what potential scenarios can we see if we do not design it properly. Let’s check if ChatGPT will detect the issue we are having! And if I should worry for my job!

The scenario will be easy – we have all tools within DevOps Team, but they are still a bottleneck in Delivery Process. This is either the Cognitive Load Scenario – or the Shadow-IT Enabler Scenario from above. Let’s see how the discussion would look like between IT Director and ChatGPT – and what would be my reaction!

Click here to read a full Case-Study discussion with ChatGPT. Below you will find a short summary – provided by ChatGPT and me 🙂

IT Director	ChatGPT	Krzysztof – IT Consultant comment
Dear ChatGPT / Krzysztof. I have a problem – my DevOps Team provided all necessary DevOps Tools for software delivery and operations. And yet, the DevOps Team is still a bottleneck in application delivery process. What can be a root cause? What are we missing?	There could be a number of reasons why your DevOps team is still a bottleneck in the application delivery process, even though they have the necessary tools. Some potential root causes could include: 1. Insufficient training or experience with the tools: It’s possible that the team members are not fully proficient with the tools they have been provided, which could be slowing down their ability to deliver applications efficiently. 2. Lack of process standardization: If the team does not have a clear set of processes in place for how to use the tools, it can lead to confusion and delays. 3. Communication and collaboration issues: If the team is not effectively communicating and collaborating with each other, it could be slowing down the delivery process. 4. Poor tool integration: If the tools are not properly integrated with each other or with the rest of the application delivery pipeline, it could be causing delays. 5. Resource constraints: It’s possible that the team is simply stretched too thin and does not have enough capacity to deliver applications as quickly as needed. Without more information, it is difficult to pinpoint the exact cause of the bottleneck you are experiencing. It may be helpful to do a root cause analysis to try to identify the specific issues that are causing delays in the application delivery process.	Wow, to be honest – I am positively surprised with an answer! Potential problems are correctly underlined: 1. Lack of training can be an indicator of incompatible Operating Model. This may be “the Cognitive Load” scenario. 2. Also, lack of process standardisation may lead us to redesigning the processes and overall responsibility model. 3. Collaboration issues are in fact a good metric to measure the services definition and fulfillment 4 & 5. Resources problems (both technical and human) can lead to lack of Operating Model implementation/compatibility with tools and services being provided by DevOps Team. The correct statement we can find also in the end – a suggestion to dig deeper into a root cause, because a bottleneck can have many causes. What I am missing in this answer is… some questions. The two first I would ask here would be: 1. What is the biggest complaint from Application Teams? 2. What is being provided by DevOps Team – and what are in Application Teams responsibility? Let’s see what ChatGPT suggest on detecting the root cause.
How can we do a root cause analysis of this situation?	There are several steps you can follow to conduct a root cause analysis of the bottleneck your DevOps team is experiencing in the application delivery process: 1. Define the problem: Clearly define the problem you are trying to solve, including when and where it occurs, and how it is affecting your team and your business. 2. Gather data: Collect data about the problem, including details about the tools and processes that are being used, as well as any relevant metrics or performance data. 3. Identify root causes: Use the data you have collected to identify potential root causes of the problem. You can use a variety of techniques for this, such as the 5 Whys method or the fishbone diagram. 4. Validate root causes: Once you have identified potential root causes, validate them by testing your hypotheses and looking for additional evidence. 5. Prioritize root causes: Identify the root causes that are most likely to be contributing to the problem, and prioritize them based on their impact and the ease with which they can be addressed. 6. Develop and implement solutions: Develop and implement solutions to address the root causes you have identified, and monitor their effectiveness to ensure that they are resolving the problem. By following these steps, you can systematically identify and address the underlying issues that are causing delays in the application delivery process.	ChatGPT provided some generic approach to have a root cause analysis performed, applicable not only for DevOps Team bottleneck detection – but it can fit here as well. What I would suggest the Customer is similar approach, but different techniques: 1. First, I would validate the full Software Delivery & Operations lifecycle, performing few Value Stream Mappings. It would allow me to see the collaboration and responsibilities boundaries between Teams. 2. Second – I would review the architecture of DevOps Tools and applications – mapping it to responsibility matrix (going low, as technically as possible). This would allow me to detect, which Operating Model type is a closest one to the Organisation. 3. Third – I would measure DevOps Maturity of the Teams, in order to design DevOps Platform Services which will deliver the value and not became the Cognitive Load / the Shadow-IT Enabler scenario.
Who should I involve on 5 why’s interview?	The 5 Whys method is a technique for identifying the root causes of a problem by asking “why” a particular issue is occurring, and then asking “why” again for each successive answer until you reach the root cause. When conducting a 5 Whys interview, it is important to involve individuals who have knowledge about the problem you are trying to solve. This might include members of the DevOps team who are directly involved in the application delivery process, as well as other stakeholders such as developers, testers, and product managers. It can also be helpful to involve people who have different perspectives on the problem, as they may have insights that others do not. For example, if the issue is related to tool integration, you may want to involve someone from the IT team who has expertise in that area. Ultimately, the specific individuals you involve in the 5 Whys interview will depend on the specifics of your situation, but the goal is to gather a diverse group of people who can provide insights and help identify the root causes of the problem.	Fully agree with ChatGPT on the audience!
Can you evaluate my DevOps Architecture?	Yes, I can certainly try to evaluate your DevOps architecture. There are several key aspects to consider when evaluating a DevOps architecture: 1. Continuous Integration and Continuous Delivery (CI/CD): A well-designed DevOps architecture should support CI/CD practices, which allow code changes to be automatically built, tested, and deployed to production. 2. Automation: Automation is a key component of a successful DevOps architecture, as it allows processes to be streamlined and reduces the risk of errors. 3. Scalability: The architecture should be designed to scale to meet the needs of your organization, both in terms of the number of applications and services being delivered, as well as the number of users and customers. 4. Security: Security should be a top concern in your DevOps architecture, as it helps protect against vulnerabilities and threats. 5. Monitoring and observability: It’s important to have monitoring and observability built into your DevOps architecture so that you can identify and troubleshoot issues as they arise. 6. Collaboration: A DevOps architecture should facilitate collaboration and communication between development and operations teams, as well as other stakeholders. By considering these factors, you can evaluate the strengths and weaknesses of your DevOps architecture and identify areas for improvement.	Well… ChatGPT can certainly provide some factors for evaluation. But evaluation is on us… Uff… I will not loose my job! For now 😉

Here is a summary of our discussion:

You mentioned that your DevOps team has been provided with the necessary tools for software delivery and operations, but they are still a bottleneck in the application delivery process.
I suggested that there could be a number of root causes for this issue, including insufficient training or experience with the tools, lack of process standardization, communication and collaboration issues, poor tool integration, or resource constraints.
To identify the root causes of the problem, I recommended following a root cause analysis process, which involves defining the problem, gathering data, identifying root causes, validating root causes, prioritizing root causes, and developing and implementing solutions.
I also mentioned that it can be helpful to involve a diverse group of people in the root cause analysis process, including members of the DevOps team and other stakeholders, as well as individuals with different perspectives on the problem.
Finally, I outlined some key aspects to consider when evaluating a DevOps architecture, including continuous integration and continuous delivery, automation, scalability, security, monitoring and observability, and collaboration.

ChatGPT provided useful insight on what may be wrong in this case-study-organisation. It underlined a potential lack of process standardisation, gaps in DevOps maturity and collaboration issues. Those factors are in fact indicators for issues related to DevOps Operating Model: responsibilities, service provisioning by Platform Team and overall application delivery processes troubles. It also suggested a root-cause detection technique, 5 Whys.

What ChatGPT didn’t do was asking right questions to detect the root-cause. And those questions are simple: the biggest complaints of Delivery Teams, who is operating which tool and what services are the DevOps Team providing to others. ChatGPT suggested potential problems or root-cause analysis techniques which we may find in books – but didn’t mentioned techniques or questions fitting the case-study scenario better. ChatGPT also cannot perform the root-cause analysis, because it requires more than text analysis – like code-analysis, architecture diagrams analysis, people communication patterns, reactions to the questions asked and… mindset. All of those are non-verbal factors for such case-study resolution.

Will ChatGPT (or other) soon replace Consultants, Programmers, Architects, Managers…?

No. Few reasons and historical analogies:

ChatGPT provides well-organized shortcuts of academic / market knowledge, which we can find in the internet. It’s a great tool for searching for information, or even potential root-causes of our problems. But it is not able to understand organizational and human factors of abstracts like DevOps Operating Model. And since Software Delivery Lifecycle is… quite simple in it’s nature and haven’t changed much in its essence since early stages of computing – it will have even more troubles understanding business abstracts. This is why it won’t replace programmers soon, rather speed-up their work.
ChatGPT is in fact new generation search enginee. It can became a new generation programming language soon. But what ChatGPT cannot do is… analysis. It does not ask questions to clarify the real human need. The same way Java haven’t replaced programmers and Google haven’t replaced experts, ChatGPT will not do it as long as it does not understand the concepts, but only search for right answers in literature. And an indicator for understanding concepts are… questions being asked.
If your work is about collecting information, without making decisions or working on abstracts… you can worry now. But I don’t see such profession in IT Industry.

The revolutionary thing about ChatGPT is an impression of talking to somebody real. It vanishes after a longer conversation, where ChatGPT is providing too many repetitive information for a specific question – but it is definitely next-generation Search Enginee. It also has a potential to became a programming language – but still, a language, not a programmer. But what ChatGPT will definitely change is the way we work with information and abstracts – we will simply spent less time searching for it.