Creating a reference architecture

In the previous sections, we looked at the different processes in IT delivery, how it is integrated with DevOps, and how this is executed in sourcing models. We have learned that it starts with a clear architecture that clearly defines the processes.

Any DevOps architecture will have to address planning, development, integration, deployment, and operations. But we have to keep in mind why we are doing DevOps, which is to achieve business goals in a faster, more agile way where we continuously improve products. The DevOps architecture does not stand on its own; it has to be linked to the enterprise architecture.

An enterprise architect will most likely start from The Open Group Architecture Framework (TOGAF). TOGAF is globally accepted as the standard for enterprise and business architecture. It uses the Architecture Development Method (ADM) to draft the architecture. The ADM is shown in the following diagram:

Figure 1.2 – The ADM cycle in TOGAF

Just like DevOps, the ADM is a cycle – except for the preliminary phase, which is where the need for an architecture is formulated. This has to be done at the tier 1 level in the sourcing model that we discussed in the previous section, IT delivery in sourcing models. The strategy and enterprise architecture is always set at tier 1.

The core of ADM is the sequence in architecture design, which is business first, and setting the principles and requirements for the actual solutions. These principles drive the architecture for data usage, the applications, and finally the technology that will be used. This is important because architecture is not about technology in the first place. Technology is purely the ability to achieve business goals at the enterprise level.

ADM assumes that the architecture is not static. It changes as soon as the business requirements change. If the business demands change, there will likely be a need to adapt the architecture and the forthcoming solutions. This is where TOGAF and DevOps meet, since the two frameworks complement each other.

The following table shows where the enterprise architecture and DevOps are complementary. To put it very simply, the enterprise architecture sets the strategic business goals, where DevOps translates this at a more tangible, tactical level and really tells us how to achieve these goals by developing products and executing operations. The following table shows the main differences between the enterprise architecture (EA) and DevOps:

In the next section, we will study the DevOps principles.

Understanding the DevOps principles

The enterprise architecture is executed on tier 1, the strategic level. This is where the goals are set for the entire enterprise. The next level is tier 2, where DevOps teams will translate the goals into product features and start developing. DevOps teams will have to work according to a set of principles.

In this section, we will look at the main principles for DevOps. In this book, we will use the six principles from the DevOps Agile Skills Association (DASA):

• Customer-centric action: Develop an application with the customer in mind – what do they need and what does the customer expect in terms of functionality? This is also the goal of another concept, domain-driven design, which contains good practices for designing.
• Create with the end-result in mind: How will the product look when it is completely finished?
• End-to-end responsibility: Teams need to be motivated and enabled to take responsibility from the start to the finish of the product life cycle. This results in mottos such as you build it, you run it, and you break it, you fix it. One more to add is you destroy it, you rebuild it better.
• Cross-functional autonomous teams: Teams need to be able to make decisions themselves in the development process.
• Continuous improvement: This must be the goal – to constantly improve the product.
• Automate as much as possible: The only way to really gain speed in delivery and deployment is by automating as much as possible. Automation also limits the occurrence of failures, such as misconfigurations.

Adhering to these principles will lead to the following architecture statements, which are at the core of DevOps:

• Automation: Following the principle of "everything is code," the next step is "automate everything." With automation, the amount of time between testing and deployment will be significantly reduced, enabling a faster release process. But automation will also lead to less manual interaction and therefore less errors.
• Collaboration: Two of the six principles are cross-functional autonomous teams and end-to-end responsibility. This can only be achieved by collaboration. Development and operations will have to work very closely together to speed up the delivery of releases. Although this is also a cultural change, collaboration requires a common toolset that supports collaboration.
• Integration: Development and operations come together, but also, business and IT come together. In DevOps, we integrate the business demands with IT delivery using user stories. Code is integrated with new functionality that is coming out of business demand. That demand is changing faster these days, so development needs to keep up by means of CI. This will lead to changes in operations as well – they will need to adopt these new developments at the same speed. With that, integration is the core of DevOps.
• Portfolio and configuration management: Automation and integration require a clear portfolio that contains the building blocks that can be automated easily. These building blocks are artifacts in the ADM cycle, and they represent packages of functionality that can be used to fulfill a requirement. A building block is reusable and replaceable; therefore, it must be clearly and specifically defined. Better said, the configuration of the building blocks needs to be well documented and brought under the control of configuration management. If done well, these building blocks will also have clear interfaces so that they can be fully automated.

In this section, we looked at the IT delivery processes and how they impact DevOps. We learned that IT delivery is driven by business demand and that this business demand is the starting point for any architecture. This is included in the TOGAF framework for the enterprise architecture. After that, we mapped the enterprise architecture to DevOps principles.

In the next section, we will merge the DevOps principles for the architecture and the IT delivery principles into a reusable reference model.

Working with the DevOps architecture reference model

The final step is to merge the DevOps principles into one model for our reference architecture. The model contains two circles. The outer circle is the product circle, while the inner circle represents the operational activities. As a logical consequence, the outer circle is governed by the enterprise itself.

The inner circle is about actually delivering the products using DevOps. There are interfaces between the outer and inner circle: collaboration, automation, integration, and configuration management.

The reference model is shown in the following diagram:

Figure 1.3 – The DevOps architecture reference model

In the outer circle, the business goals are translated into the architecture. From the architecture, a portfolio is created with building blocks to create products and services. Products are released to the market and adopted, but due to changing demands, there will be requests for changes. These changes will drive enterprise planning and ultimately change the business goals, meaning that the business will constantly have to adapt to changing demands. This is the field of enterprise architecture.

The plans and the actual builds are executed in the inner circle. In this circle, the product is broken down into product backlog items that will be developed and eventually operated on by DevOps teams. These teams do not operate by themselves, but on triggers from the outer circle. That's what the interface layer is about – it's the interface between the business and the execution teams doing IT delivery. There's collaboration between architecture and development. Releases should be automated as much as possible, requests and changes must be integrated with planning and the backlog of the DevOps teams, and builds that are pushed to production must be monitored and brought under the control of configuration management so that the architecture and portfolio stay consistent in case of changes.

Let's have a look at how this would work in practice by plotting personas into the model. This will result in a DevOps workflow for enterprises, as shown in the following diagram:

Figure 1.4 – DevOps workflow for enterprises

Here, we have created a model where the enterprise has full control over its portfolio and products. Yet, it can improve quality and speed up delivery by working with combined, multidisciplinary teams – even those that come from different suppliers.

In the next section, we will study the final, lowest tier in our model and discover various DevOps components.