Chapter 2: Managing DevOps from Architecture

In the previous chapter, we learned about the different DevOps components, which comprise automation, collaboration, integration, and configuration management components. In this chapter, we will learn in more detail how to design these components and how to manage the DevOps cycle from these components. We will learn that automation and integration start with standardizing building blocks, called artifacts. These artifacts are linked with a portfolio that is defined by the enterprise architecture. Before we get to launch DevOps projects using automation and integration, we need to understand the business strategy and demand for architecture.

After completing this chapter, you will be able to identify the different components of demand management and how this drives portfolio management. You will also learn what the various stages are in continuous integration (CI) and how automation can help enterprises in speeding up deployment processes...

Assessing demand as input for the architecture

You can't just start with a DevOps project—a business will need to know what they want to achieve before they launch projects. For that matter, there's no difference between a traditional Waterfall project and DevOps in an Agile way of working—you need to know where you're going. That's a very simple explanation of something that is called demand management. In this section, we will learn about demand as input for an architecture and how this leads to projects.

Demand management can be defined as a process wherein an enterprise collects and prioritizes ideas to improve business outcomes. To be able to do that, the enterprise needs to assess the demands from the outside, meaning the market—in other words: What do customers want? But it also needs to assess whether the current portfolio is still up to date and that ongoing projects will still deliver the desired outcome. Portfolio management is...

Designing and managing automation

In this section, we will discuss automation for DevOps. For starters, automation is not only about tools, although we will discuss tools at the end of this section. The first questions that architects will need to answer regard what they need to automate and why. It's not about the tools but about the process.

First, we need to answer the following question: Why would we need automation? The answer to that question is because of standardization. The reason for businesses to adapt DevOps is because they want to speed up delivery processes. The only way to do that is by standardization of building blocks, workflows, processes, and technologies. By implementing and adhering consistently to standards, companies will limit varieties in the delivery chain and can then start automating it. The big trick in automation is cutting down the waiting time.

Before companies turned to DevOps, IT delivery was driven by waiting time. Developers had to...

Implementing and managing configuration management

In the previous section, we learned that automation starts with version control and configuration items that form an application package in an artifact's repository. In this section, we will study how we can manage these artifacts.

Automation can only be done when building blocks (artifacts) and processes are standardized. Standardization requires three components, outlined as follows:

• Portfolio and portfolio management: A portfolio is the translation of the business strategy and the products that a business delivers to its customers. Those products consist of several artifacts: product components and processes. So, a portfolio is at the strategic level of an enterprise, whereas products and artifacts sit at a tactical level. A portfolio is defined by the enterprise architecture, products, and artifacts that are managed at a business-unit and project level. In short, products can't exist without a definition in...

Designing and managing integration

In this section, we will learn more about CI. First, we will look at the development and deployment of application code. Next, we will learn about the integration of code pipelines for applications and the infrastructure. Somewhere, the application code and the IaC have to merge together with specific configuration packages. Only then will we have a fully integrated model.

Let's look at a definition of integration first. This refers to an automated series of tasks to version, compile, package, and publish an application. This includes testing, whereby unit tests are used to validate that existing code performs well without interruptions. Integration tests run to ensure no integration issues occur. Additional checks, such as static code analysis, can be included as well to increase quality and feedback.

The CI/CD pipeline—and with that, the automation—starts with a merge of source code. This code is transformed to a build,...

Designing and managing collaboration

To put it very simply, DevOps only succeeds if teams work together. Teams can collaborate if they use the same processes and, indeed, the same toolsets. In DevOps, collaboration ties processes and technology together to enable teams to join forces.

In Chapter 1, Defining the Reference Architecture for Enterprise DevOps, we saw that a lot of enterprises have outsourced major parts of their IT. This makes collaboration hard, every now and then. DevOps requires that teams carrying out operations and that are part of a certain sourcing partner or vendor work together with developers that come from a different company. It's up to the enterprise to set the scene, engagement rules, and co-working principles. The ownership of that can only be at an enterprise level.

In enterprises, it's very rare that only one team is completely responsible for an application. Often, there are more teams involved, and—even—more than one supplier...

Summary

This chapter started with an overview of demand management as input for an architecture. We learned that assessing business demand is the key driver for portfolios. In turn, a portfolio defines the artifacts and building blocks that we use to develop products, services, and, as such, applications. Since demand is changing fast, enterprises will need to speed up deployment processes. This can be achieved by automating as much as possible. Automation is done through pipelines, and in this chapter, we've learned what the different components are in architecting both application deployment and infrastructure pipelines.

In the last section, we discussed collaboration that is crucial in CI/CD, using DevOps. Teams will be formed by engineers with different skill sets, and they even may be hired from different companies, something we see frequently at large enterprises that have outsourced their IT. Therefore, enterprises will need to encourage strong collaboration, based...

Questions

1. Demand management is a process of collecting ideas and identifying opportunities for future products and services that are in a portfolio. Rate the following statement true or false: the business case is not relevant for demand management.
2. One of the first tests is a test without actually running the code. What do we call this test?
3. The promotion path contains various stages. What are these stages, and in what order are they set?

Further reading

• Demand management as a critical success factor in portfolio management. Paper presented at PMI® Global Congress 2016 by Romano, L., Grimaldi, R., & Colasuonno, F. S. (2016):

  https://www.pmi.org/learning/library/demand-management-success-factor-portfolio-10189

• Kanban and Scrum – Making the Most of Both, Henrik Kniberg and Mattias Skarin:

  https://www.infoq.com/minibooks/kanban-scrum-minibook/